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ABSTRACT 


The  United  States  Navy  owns  four  salvage  ships  and  four  towing  ships  that  will 
reach  the  end  of  their  40-year  life  expectancy  in  2019.  The  program  manager  for  these 
vessels  has  a  set  of  desirable  performance  requirements  for  a  new  ship  class,  T-ARS(X), 
which  combines  the  capabilities  from  both  the  salvage  and  towing  ship  classes.  The  need 
to  develop  a  recapitalization  strategy  based  on  either  designing  a  new  ship  class  based  on 
these  desirable  requirements  or  purchasing  commercial  capabilities  based  on  the  salvage 
and  towing  community’s  needs  is  paramount.  Meanwhile,  the  Department  of  Defense 
(DoD)  has  shifted  defense  planning  from  the  specific  service  requirements  generating 
system  (RGS)  acquisition  to  the  Joint  Capabilities  Integration  and  Development  System 
(JCIDS)  approach  that  focuses  on  requirements  generation  based  on  customer  need.  This 
thesis  explores  how  to  use  systems  architecting  principles  in  the  context  of  model-based 
systems  engineering  (MBSE)  to  incorporate  the  capabilities  needed  for  towing  and 
salvage  recapitalization  into  a  cohesive  framework  for  developing  the  T-ARS(X) 
requirement  specification.  The  CORE  design  tool  is  used  to  implement  the  MBSE 
architecting  process  using  the  Naval  Architecture  Elements  Reference  Guide  (NAERG) 
and  standardized  operational  tasks  to  create  DODAE  vl.5  products  from  system  models. 
The  requirements  generated  from  the  architecture  model  are  compared  with  the  current, 
combined  towing  and  salvage-capable  commercial  platforms  for  analysis.  Based  on  the 
methodology  presented,  the  towing  and  salvage  community  now  has  the  basis  to  perform 
a  capabilities-based  analysis  of  alternatives  (AoA)  for  the  T-ARS(X)  recapitalization. 
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EXECUTIVE  SUMMARY 


The  United  States  Navy  has  a  number  of  considerations  relating  to  the 
recapitalization  of  their  ocean-towing  and  salvage  ships,  which  are  in  need  of 
replacement  within  the  next  10  to  20  years.  The  recapitalization  alternative  acquisition 
strategies  are  either  building  a  new  platform  or  purchasing  from  the  commercial  market. 
The  motivation  for  this  thesis  is  to  develop  a  capabilities-driven  architecting  process, 
with  a  model-based  systems  engineering  (MBSE)  approach,  based  on  a  thorough 
consideration  of  capabilities.  The  architecture  model  is  demonstrated  in  order  to  provide 
a  future  basis  to  complete  an  analysis  of  alternatives  (AoA)  that  considers  new  platform 
options  versus  acquisition  within  the  commercial  market.  The  end  result  of  this  thesis 
can  enable  effective  decision-making  efforts  into  the  recapitalization  of  the  future  salvage 
platform  force  structure  by  its  stakeholders.  Efficient  MBSE  practices  can  also  prevent 
the  expenditure  of  resources  in  areas  that  may  not  be  feasible  in  the  period  of 
development,  thus  ensuring  a  successful,  long-term  program  for  future  salvage 
operations.  The  motivation  for  a  DoD-wide  transformation  to  a  capabilities-based 
systems  architecting  approach  was  the  realization  that  systems  development  consistently 
resulted  in  outcomes  that  did  not  effectively  meet  the  needs  of  stakeholders.  The 
integration  of  architecture-based  engineering  helps  to  generate  traceable  requirements, 
driven  by  stakeholder’s  needs. 

“There  is  a  great  need  to  describe  a  process  to  ensure  that  the  architecture,  the 
arrangement  of  elements  and  their  relationships,  is  well-defined  and  addresses  the  needs 
of  the  stakeholders”  (DODAE,  2004).  Architecture  frameworks  are  used  by  the  DoD  to 
provide  a  consistent  documentation  basis  to  describe  stakeholder  views  of  a  system 
architecture.  To  achieve  an  efficient,  integrated  system  architecture,  the  needs  of  all 
concerned  stakeholders  and  their  conflicting  ideas  of  the  system  outcomes,  must  be 
considered.  An  integration  of  systems  architecting  and  engineering  methods  within  a 
model-based  process  would  be  useful  in  developing  an  interoperable  system  design  based 
comparative  analysis  of  alternatives  opportunities  that  could  be  envisioned  for  future 
system  of  systems. 

xvii 


The  U.S.  Navy  Towing  and  Salvage  platform  can  be  architected  in  the  context  of 
a  System  of  Systems  (SoS)  from  an  identified  set  of  stakeholder  needs.  The 
identification  of  the  salvage  platform  SoS  begins  with  the  mission  objectives  from  the 
concept  of  operations  (CONOPS)  of  the  salvage  force,  continues  with  the  development  of 
a  design  reference  mission  (DRM),  which  leads  to  an  appropriate  architecture  supported 
by  modeling  and  simulation.  A  major  challenge  in  the  architecting  process  is  developing 
an  architecture  so  that  the  system  elements  are  complete  and  consistent  with  one  another. 

The  process  of  identifying  capability  needs,  analyzing  system  functions,  and 
allocation  to  system  physical  components  cannot  currently  be  satisfactorily  completed 
given  existing  architecture  framework  products  alone.  The  amount  of  data,  when 
complying  with  architecture  standards  such  as  the  Department  of  Defense  Architecture 
Framework  (DoDAF),  is  too  large  to  manipulate  manually.  An  architecting  tool  is  a  great 
asset  that  is  used  to  verify  that  the  data  is  consistent  and  that  all  element  connections 
remain  with  their  associated  counterparts.  The  CORE  Architecture  Data  Model  (CADM) 
can  aid  is  this  task  by  integrating  the  architectural  frameworks  within  the  SoS 
development  process  and  the  Systems  Modeling  Language  (SysML)  representation  of  the 
SoS  model.  The  development  of  the  CORE  architecting  method  can  define  the  future 
salvage  platform  SoS  and  adequately  identify  the  capability-based  requirements  from  the 
operational  mission  objectives.  CORE  can  provide  a  clear  path  from  mission  area  needs 
to  a  set  of  clear  and  defined  requirements;  achieving  a  product  able  to  perform  both 
towing  and  salvage  operations. 

This  thesis  reports  the  development  of  an  architecting  process  that  directly 
addresses  the  recapitalization  of  a  future  towing  and  salvage  ship  platform,  preemptively 
named  T-ARS(X),  with  the  development  of  both  legacy  T-ARS  and  T-ATE  capabilities. 
The  model-based  system  architecture  process  utilizes  CORE  modeling  techniques  to 
achieve  top-level  coherent  requirements  to  be  used  in  an  analysis  of  the  commercial 
market  capabilities,  and  will  be  used  as  a  foundation  for  future  capability-based 
architectural  modeling.  The  architecture  developed  in  this  thesis  demonstrates  a  way 
forward  for  a  complete  T-ARS(X)  system  model  with  further  development  to  include  all 
T-ARS(X)  operational  tasks,  components,  mission  areas  and  capabilities. 
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I.  INTRODUCTION 


The  United  States  Navy  has  a  number  of  considerations  relating  to  the 
recapitalization  of  their  ocean-towing  and  salvage  ships.  Currently,  the  Navy  operates 
four  towing  (T-ATF)  and  four  salvage  (ARS)  ships  that  are  in  need  of  replacement  within 
the  next  10  to  20  years.  The  need  for  ARS  and  T-ATF  recapitalization  has  been  verified 
and  alternative  acquisition  strategies,  such  as  building  a  new  platform  or  purchasing  from 
the  commercial  market,  are  being  entertained  (Sperling  &  Keenan,  2006). 

Up  to  nine  replacement  ARS/T-ATF  ships,  with  a  consideration  to  move  to  a 
single-hull  T-ARS(X),  are  needed  to  fulfill  the  combined  peacetime  and  wartime 
requirements  described  in  the  ARS  and  T-ATF  Concept  of  Operations  (CONOPS).  This 
requirement  was  verified  by  United  States  Fleet  Forces  (USFF),  Center  for  Naval 
Analysis  (CNA),  and  Naval  Sea  Systems  Command  (NAVSEA),  based  on  current 
mission  needs  and  the  CONOPS  of  the  towing  and  salvage  ships  of  the  Navy  (Sperling  & 
Keenan,  2006).  Analysis  of  alternative  (AoA)  possibilities  to  meet  the  Navy’s  towing 
and  salvage  requirements  include  building  a  new  ship,  purchasing  commercial  platforms, 
or  a  combination  of  both.  For  the  alternative  investment  strategy  of  purchasing 
commercial  platforms,  a  contractor-owned  contractor-operated  (COCO)  option  has  been 
demonstrated  by  CNA  to  be  more  cost  effective,  based  on  current  towing  and  salvage 
requirements  (Sperling  &  Keenan,  2006).  In  order  to  consider  stakeholder  needs  in  the 
decision-making  process  for  such  a  future  Fleet  investment,  a  study  of  the  architecture  of 
the  elements  involved,  and  their  relationships,  should  be  conducted.  The  ocean-towing 
and  salvage  capability  is  a  System  of  Systems  (SoS)  and  the  need  to  define  an  adequate 
architecture  is  key  to  identifying  the  top-level  requirements  that  are  crucial  in 
determining  which  investment  strategy  the  Navy  should  consider. 

The  motivation  for  this  thesis  is  to  develop  a  capabilities-driven  architecture 
development  process,  integrated  into  a  model-based  systems  engineering  methodology, 
and  to  demonstrate  a  thorough  consideration  of  capabilities  to  develop  the  basis  for  an 
AoA  that  considers  requirements  for  both  new  platform  options  as  well  as  COCO  assets 
from  the  commercial  market.  Key  outcomes  described  in  this  thesis  are: 
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•  An  architecture  and  architecture-based  requirements  generation  process 
(with  focus  on  stakeholder  needs)  ideally  suited  to  future  salvage  platform 
force  structure  development. 

•  A  model-based  systems  engineering  (MBSE)  process  that  integrates 
architecting  principles,  from  engineering  requirements  definition  to 
physical  architecture  integration,  for  fusing  the  diverse  assets  involved  in 
this  complex  system  (Whitcomb,  2008). 

•  A  set  of  architectural  and  realizable  requirement  specifications  based  on 
the  salvage  community’s  needs. 

•  An  architecture  based  on  capabilities  mapped  to  mission  activities. 

•  A  market  analysis  of  the  COCO  possibilities  against  requirements. 

The  end  result  is  a  method  that  enables  effective  decision-making  efforts  for  the 
recapitalization  of  the  “Future  Salvage  Platform  Force  Structure,”  as  well  as  preventing 
the  expenditure  of  resources  in  areas  that  may  not  be  feasible  in  the  period  of 
development,  thus  ensuring  a  sound  basis  of  architecture  for  the  future  salvage  fleet 
(Whitcomb,  2008). 

The  development  of  this  model-based  methodology  requires  consideration  of 
many  newly  architectural  aspects  of  systems  -  from  systems  engineering  and 
architecting,  capabilities-based  planning,  SoS,  and  architectural  elements.  A  brief  review 
of  topics  is  presented  in  order  to  set  the  context  for  the  description  of  the  final  model- 
based  methodology  in  this  thesis. 

A,  SYSTEMS  ENGINEERING 

Systems  engineering  is  generally  used  to  describe  the  set  of  processes  applied  to 
the  development  of  a  system  that  consists  of  two  significant  disciplines:  the  technical 
knowledge  domain  in  which  the  systems  engineer  operates,  and  systems  engineering 
management  (DAU,  2001).  Systems  engineering  spans  the  progression  from  customer 
need  discovery  to  the  disposal  of  the  system.  “A  system  is  an  integrated  group  of 
separate  entities  which  interact  to  perform  a  function”  (DAFl,  2001).  This  integrated 
group  embodies  a  set  of  relationships  among  the  composite  of  people,  products,  and 
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processes,  providing  a  eapability  to  satisfy  a  stated  need  or  objeetive  (DAU,  2001). 
Systems  engineering  is  defined  as 


...  a  braneh  of  engineering  whose  responsibility  is  ereating  and  exeeuting 
an  interdiseiplinary  proeess  to  ensure  that  eustomer  and  stakeholder’s 
needs  are  satisfied  in  a  high  quality,  trustworthy,  eost  effieient  and 
sehedule  eompliant  manner  throughout  a  system’s  entire  life  eyele,  from 
development  to  operation  to  disposal  (INCOSE,  2008). 

Systems  engineering  provides  the  proeesses  to  define  system  performanees,  eosts, 
sehedule,  and  risks. 

In  2004,  the  Under  Seeretary  of  Defense  for  Aequisition,  Teehnology,  &  Logisties 
(USD  AT&L)  issued  a  Poliey  for  Systems  Engineering  in  the  Department  of  Defense 
(DoD)  to  “drive  good  systems  engineering  proeesses  and  praetiees  baek  into  the  way  we 
do  business.”  The  engineering  proeess  used  in  this  thesis  is  an  iterative  development 
proeess  of  a  system,  with  eonsideration  for  the  needs  of  the  towing  and 
salvage  eommunity. 

B,  SYSTEMS  ENGINEERING  PROCESS 

The  Systems  Engineering  Proeess  (SEP)  is  a  eomprehensive,  iterative  and 
reeursive  problem  solving  proeess,  applied  sequentially  top-down  by 
integrated  teams.  It  transforms  needs  and  requirements  into  a  set  of 
system  produet  and  proeess  deseriptions,  generate[s]  information  for 
deeision  makers,  and  provides  input  for  the  next  level  of  development. 

The  systems  engineering  proeess,  displayed  in  figure  1,  is  applied 
sequentially,  one  level  at  a  time,  adding  additional  detail  and  definition 
with  eaeh  level  of  development  (DAU,  2001). 
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Process  Input 
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•  Program  Decision  Requirements 

•  Requ'rements  Applied  Through 
Specifications  and  Standards 


Functional  Analysis'Allocation 

•  Decompose  to  Lovirer-Level  Functions 

•  Allocate  Performance  and  Other  Limittrig  Requirements  |— | 
to  All  Functional  Levels 

•  Defne'Refine  Functional  Interfaces  (Internal/External) 
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•  Trade-Off  Studies 

•  Effectiveness  Analyses 

•  Risk  Management 

•  Configuration  Management 

•  Interface  Management 

■  Data  Management 

■  Perfromance  kfoasurement 

-  SEMS 
-TPM 

-  Technical  Reviews 


Design  Loop 

Synthesis 

Transform  Architectures  {Functional  to  Physical) 
Define  Alternative  System  Concepts.  Configuraton 
Items  and  System  Elements 
Select  Prefe'red  Product  and  Process  Solutions 
Define-'Pefine  Physical  Interfoces  (Internal'Externar 


Related  Terms: 


Process  Output 


Customer  =  Organizations  responsiPle  for  Primary  Functions 
Primary  Furrctions  -  Development.  Productiorv'Construct«n.  Verification. 

Deployment.  Operations,  Support.  Training,  Disposal 
Systems  Elements  *  Hardware.  Software.  Personnel.  Facilities.  Data.  Material. 
Services.  Techniques 


•  Development  Level  Dependent 

-  Decision  Datasase 

-  System/Configuration  Item 
Architecture 

-  Specificatons  and  Baselines 


Figure  1.  Systems  Engineering  Proeess  Description  (From:  DAU,  2001) 

A  typical  systems  engineering  process  begins  with  identifying  the  initial  problem 
statement  and  list  of  stakeholders.  After  confirmation  that  there  is  a  need  to  solve  the 
problem,  the  next  step  is  to  refine  and  reiterate  the  problem  statement,  confirm  the 
coordination  between  all  important  stakeholders,  and  to  analyze  the  process  inputs. 
Systems  engineering  process  inputs  consist  primarily  of  the  customer’s  needs,  objectives, 
requirements,  and  project  constraints. 

Next,  a  requirements  analysis  is  accomplished  and  is  used  to  develop  complete 
and  understandable  set  of  performance  requirements  that  define  what  the  system  must  do 
and  how  well  it  must  perform.  These  requirements  are  based  on  customer  needs. 

Requirements  analysis  must  clarify  and  define  functional  requirements  and 
design  constraints.  Functional  requirements  define  quantity  (how  many), 
quality  (how  good),  coverage  (how  far),  time  lines  (when  and  how  long), 
and  availability  (how  often).  Design  constraints  define  those  factors  that 
limit  design  flexibility,  such  as:  environmental  conditions  or  limits; 
defense  against  internal  or  external  threats;  and  contract,  customer  or 
regulatory  standards  (DAU,  2001). 
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Once  the  requirements  have  been  identified  and  defined,  they  need  to  be  mapped 
to  funetions,  whieh  must  be  analyzed  and  allocated  into  lower-level  functions. 
Higher-level  functions  can  be  analyzed  by  decomposing  them  into  lower-level  functions. 
“The  result  is  a  description  of  the  produet  or  item  in  terms  of  what  it  does  logically  and  in 
terms  of  the  performance  required”  (DAU,  2001).  Lower- level  functions  derived  from 
higher-level  functions,  presented  within  a  functional  hierarchy  diagram  and  displayed  in 
Figure  2,  provide  a  better  understanding  of  what  the  actual  functions  are  and  how  they  are 
associated  with  each  other.  This  description  is  called  a  functional  architecture  and 
provides  “information  essential  to  optimizing  physical  solutions”  (DAU,  2001). 


Figure  2.  Funetional  Hierarehy  for  Conduct  Salvage  Operations 


After  all  funetions  have  been  identified,  each  must  then  be  matehed  to  a 
requirement  for  use  in  developing  the  physical  architecture  initialization  through  design 
synthesis.  Design  synthesis  is  the  process  of  defining  the  physical  architecture  of  the 
system  in  terms  of  its  physical  elements.  Each  physical  element  must  meet  at  least  one 
functional  requirement.  “The  physical  architecture  is  the  basic  structure  for  generating 
the  specifications  and  baselines”  (DAU,  2001).  During  the  physical  architecture 
synthesis,  it  is  consistently  aligned  with  the  functional  architecture,  eventually  with 
physical  system  performance  verified  to  the  requirements  in  a  design  loop.  “The  design 


5 


loop  permits  reconsideration  of  how  the  system  will  perform  its  mission,  and  this  helps 
optimize  the  synthesized  design”  (DAU,  2001).  The  verification  process  is  a  formal 
testing  and  evaluation  procedure  for  ensuring  that  all  requirements  will  be  met  by  the 
proposed  solution. 

The  set  of  systems  analysis  and  control  process  is  used  to  evaluate  the  system’s 
design  and  alternative  approaches  during  each  phase  of  the  systems  engineering  process. 

The  purpose  of  Systems  Analysis  and  Control  is  to  ensure  that  solution 
alternative  decisions  are  made  only  after  evaluating  the  impact  on  system 
effectiveness  and  that  product  and  process  design  requirements  are 
directly  traceable  to  the  functional  and  performance  requirements  they 
were  designed  to  fulfdl  (DAU,  2001). 

Once  the  system  functions  have  been  traced  to  the  system  requirements,  the  next  phase  is 
to  design  the  system  configuration  and  begin  baseline  definition.  For  DoD,  system 
output  is  “any  data  that  describes  or  controls  the  product  configuration  or  the  processes 
necessary  to  develop  that  product”  (DAU,  2001). 

One  of  the  most  important  characteristics  of  the  systems  engineering  process  is 
synergy.  Identifying  the  interactions  of  all  components  of  a  system,  in  the  sense  that  the 
composite  or  total  system  achieves  more  than  the  component  systems,  can  achieve 
greater  efficiency  in  the  development  that  suits  the  ever-evolving  nature  of  complex 
systems.  The  need  to  accommodate  evolving  systems  requires  the  development  of 
appropriate  architectural  infrastructures  through  a  process  that  includes  aspects  of  both 
architecture  and  engineering. 

C.  SYSTEMS  ARCHITECTURE  AND  ARCHITECTING 

The  early-stage  activities  involved  in  systems  engineering  have  salient  features 
more  related  to  the  field  of  architecture  than  that  of  engineering.  The  difference  between 
architecting  and  engineering  is  described  in  terms  of  “art  and  science”  (Rectin  &  Maeir, 
2002).  Architecting  focuses  on  the  architecture,  or  art,  and  patience  of  a  designer 
necessary  to  complement  the  complexity  of  engineering  the  system.  Architecting 
contrasts  with  engineering  in  that  it  is  “nonanalytic,  difficult  to  clarify,  and  seldom  taught 
formally  in  industry”  (Rectin  &  Maeir,  2002).  Architecting  plays  a  vital  role  in  creating 
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new  types  of  eomplex  systems  that  incorporate  evolving  technologies  (Rectin  &  Maeir, 
2002).  The  need  for  architecting  is  shown  in  that  it  complements  engineering  in 
accounting  for  the  immeasurable;  e.g.,  multiple  stakeholders,  perceptions  of  worth, 
safety,  affordability,  political  acceptance,  and  environmental  impact.  Therefore,  the 
development  of  an  architecture  in  the  earliest  stages  of  a  systems  engineering  process  is 
justified. 

1,  Systems  Architecture 

In  1987,  John  Zachman,  author  of  the  Zachman  Framework  for  Enterprise 
Architecture,  wrote  “To  keep  the  business  from  disintegrating,  the  concept  of  information 
systems  architecture  is  becoming  less  of  an  option  and  more  of  a  necessity.”  From  that 
statement,  systems  architecture  has  evolved  and  become  the  model  around  which  major 
organizations  view  and  communicate  their  enterprise  information  infrastructure 
(ZIFA,  2008). 

There  is  no  universally  agreed  on  definition  of  a  systems  architecture.  Various 
organizations  define  it  in  different  ways,  including: 

•  The  arrangement  of  elements  and  subsystems  and  their  functional 
allocation  to  meet  system  requirements  (INCOSE,  2008). 

•  The  arrangement  of  the  functional  elements  into  physical  blocks  (Ulrich  & 
Eppinger,  2004). 

•  The  arrangement  of  function  and  feature  that  maximizes  some  objective 
(Ring,  2001). 

•  The  embodiment  of  concept,  and  the  allocation  of  physical/informational 
function  to  elements  of  form  and  definition  of  structural  interfaces  among 
the  elements  (Crawley,  2003). 

•  The  structure  (in  terms  of  components,  connections,  and  constraints)  of  a 
product,  process,  or  element  (Rechtin  &  Maier,  2002). 

•  The  structure  of  components,  their  relationships,  and  the  principles  and 
guidelines  governing  their  design  and  evolution  over  time 
(DoDAE,  2007). 

In  business,  outside  of  DoD,  “an  architecture  description  is  a  formal  description  of 
a  system,  organized  in  a  way  that  supports  reasoning  about  the  structural  properties  of  the 
system.  It  defines  the  system  components  and  provides  a  plan  from  which  products  can 
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be  procured.  It  thus  enables  you  to  manage  investment  in  a  way  that  meets  business 
needs”  (TOGAF,  2007). 

An  architecture,  then,  is  an  organized  set  of  interconnected  system  capabilities, 
functions,  and  components;  their  relationships  to  each  other,  and  to  the  environment;  and 
the  principles  guiding  its  design  and  evolution  (IEEE  STD  1471,  2000).  Typically,  an 
architecture  is  developed  because  key  people  (stakeholders)  within  the  organization  have 
concerns  that  need  to  be  addressed  by  the  systems.  The  role  of  the  architect  is  to  address 
these  concerns  (Whitcomb,  2008): 

•  Identifying  and  refining  the  stakeholder  requirements. 

•  Developing  architectural  views  and  models  that  show  how  the  concerns 
and  the  requirements  are  going  to  be  addressed. 

•  Showing  the  trade-offs  that  are  going  to  be  made  in  reconciling  the 
potentially  conflicting  concerns  of  different  stakeholders. 

The  system  architect  develops  the  architecture  early  in  the  systems  engineering  process. 

2,  Systems  Architecting 

Architecting  deals  primarily  with  undefined  situations  with  immeasurable 
quantities,  focusing  on  the  qualitative  aspects  of  the  system.  Engineering  deals  primarily 
with  physical  and  scientific  situations  with  measurable  quantities  and  concepts,  using 
analytic  tools,  making  it  compatible  with  the  beginning  stages  of  the  systems  engineering 
process  (Maier  &  Rechtin  2002).  Eigure  3  presents  a  summary  of  the  characteristic 
differences  between  architecting  and  engineering. 

Systems  architecting  (SA)  employs  synthesis  of  form  to  iteratively 
compose  separate  elements  to  form  a  coherent  whole,  or  a  representation 
of  a  coherent  whole,  that  can  serve  as  an  initial  point  for  systems 
development.  Architecting  synthesizes  this  initial  point  or  architectural 
specification  from  the  collected  vision,  goals,  constraints,  and  other  needs 
of  the  stakeholders  in  the  to-be-developed  system.  Architecture 
specification  can  be  defined  as  an  architectural  description  to  which  all 
system  implementations  must  adhere;  and  a  set  of  principals,  practices, 
and  constraints  guiding  implementation,  operation,  and  evolution  of  the 
developed  system  (Mercer,  2008). 
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Systems  architecting  and  systems  engineering  are  often  described  in  a  single 
systems  engineering  process,  typically  because  systems  architecting  is  not  addressed 
individually,  but  is  simply  defined  by  the  steps  used  in  the  very  early  stage  of  the  process. 
Architecture  exists  for  the  purpose  of  (a)  achieving  a  well-defined  system  in  the 
application  domain,  and  (b)  achieving  the  eventual  system  developed  in  the  solution 
domain,  that  (c)  can  be  used  to  meet  desired  capabilities  over  a  specific  time  frame  or  set 
of  time  frames.  The  act  of  creating  an  architecture  is  fundamentally  different  from  the  act 
of  creating  a  product  through  engineering. 


Architecting 

Engineering 

Synthesis  of  Form  ► 

◄  Analysis  of  Function 

•  Holistic 

•  Reductionist 

•  Manipulates  complexity 

•  Reduces  complexity 

•  Satisficing  -  client  satisfaction 

•  Optimizing  -  technical  optimization 

•  Qualitative  worth 

•  Quantitative  costs 

•  Abductive 

•  Deductive 

•  Heuristics 

•  Algorithms 

•  Value  in  the  “what” 

•  Value  in  the  “how” 

•  Emphasis  on  meaning  (semantics) 

•  Emphasis  on  arrangement  (syntax) 

•  External  interfaces  -  Openness 

•  Internal  interfaces  -  Boundedness 

•  Abstraction;  notional 

•  Precision;  exact 

•  Produces  architectural  specification 

•  Produces  implementation  specification 

•  Architectural  “design” 

•  Engineering  “design” 

Figure  3.  Comparison  of  Architecting  and  Engineering  (From;  Mercer,  2008) 

D.  SYSTEM  OF  SYSTEMS  (SoS) 

The  concept  of  systems  has  been  recently  expanded  to  directly  define  “SoS”  as 
unique  from  “systems.”  An  SoS  is  defined  as  “a  set  or  arrangement  of  systems  that 
results  when  independent  and  useful  systems  are  integrated  into  a  larger  system  that 
delivers  unique  capabilities”  (JCIDS  2005).  The  SoS  concept  does  not  specify  a  need  for 
particular  new  methods;  instead,  it  suggests  a  new  way  of  thinking  for  solving  complex 
interactions  of  technology,  policy,  and  economics.  “System  of  systems  study  is  related  to 
the  general  study  of  architecting,  complexity  and  systems  engineering,  but  also  brings  to 
the  forefront  the  additional  challenge  of  design”  (DeLaurentis,  2007). 
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The  basic  needs  to  accommodate  system  life-cycle  changes  are  identified  as: 
systems  engineering  organization  for  life-cycle  management,  developing  appropriate 
infrastructures,  and  adopting  a  systems  management  paradigm  for  SoS  evolution  to 
ensure  interoperability.  Appropriate  architecting  is  suggested  as  a  major  need  to  ensure 
this  (Boardman  &  Sauser,  2008).  There  have  been  a  number  of  other  similar 
characterizations.  For  example.  Sage  and  Biemer  (2007)  provide  the  following  five 
characteristics  differentiating  an  SoS  from  monolithic  systems: 

•  Autonomy  -  constituent  systems  exercise  autonomy  in  order  to  fulfill  the 
purpose  of  the  SoS. 

•  Belonging  -  constituent  systems  choose  to  belong  to  the  SoS,  based  on 
cost/benefits  basis. 

•  Connectivity  -  constituent  systems  provide  dynamic  connectivity  to 
enhance  overall  SoS  capability. 

•  Diversity  -  a  product  characteristic  of  an  SoS  not  available  from 
single  systems. 

•  Emergence  -  capability  is  provided  that  was  not  originally  foreseen  during 
development,  leading  to  early  detection  and  elimination  of 
undesirable  behaviors. 

Following  the  stated  characteristics,  an  SoS  is  defined  by  Boardman  and  Suaser 
(2008)  as 

...  a  large-scale,  complex  system,  involving  a  combination  of  components 
which  are  systems  themselves,  achieving  a  unique  end-state  by  providing 
synergistic  capability  from  its  component  systems,  and  exhibiting  a 
majority  of  the  following  characteristics:  operational  and  managerial 
independence,  geographic  distribution,  emergent  behavior,  evolutionary 
development,  self-organization,  and  adaptation. 

Sage  and  Biemer  (2007)  summarize  the  concept  of  defining  an  SoS  by  identifying 
five  typical  characteristics  of  a  system  family: 

•  A[n]  SoS  is  composed  of  systems  that  are  independent  and  useful  in  their 
own  right. 

•  The  component  systems  in  an  SoS  not  only  can  operate  independently; 
they  generally  do  operate  independently  to  achieve  an  intended  purpose. 

•  The  geographic  dispersion  of  the  component  systems  is  often  large. 

•  A[n]  SoS  performs  functions  and  carries  out  purposes  that  are  not 
necessarily  associated  with  any  component  system,  leading  to  behaviors 
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that  are  emergent  properties  of  the  entire  SoS  and  not  the  behavior  of  any 
component  system. 

•  The  development  of  an  SoS  is  generally  evolutionary  over  time. 

Given  the  above  definition  of  SoS,  the  connection  between  integrated 
architectures  and  an  SoS  is  presented  in  the  context  of  this  thesis. 


E.  SYSTEM  OF  SYSTEMS  (SoS)  ENGINEERING 


Conducting  SoS  is  quite  similar  to  conducting  systems  engineering  (SE),  though 
“the  development  of  a  system  of  systems  solution  will  involve  trade  space  between  the 
systems,  as  well  as  within  an  individual  system’s,  performance”  (DAG,  2006).  Table  1 


displays  the  differences  between  traditional  SE  and  the  SoS  engineering  process. 


Traditional  Systems 

System-of-Systems 

Engineering 

Engineering 

Purpose 


System 

Architecture 


System 

Interoperability 


System 

“ilities” 


Acquisition 

and 

Management 


Anticipation  of 
Needs 


Development  of  single  system  to  meet 
stakeholder  requirements  and  defined 
performance 

System  architecture  established  early 
in  lifecycle  and  remains  relatively 
stable 

Defines  and  implements  specific 
interface  requirements  to  integrate 
components  in  system 


Reliability,  Maintainability,  Availability 
are  typical  ilities 

Centralized  acquisition  and 
management  of  the  system 


Concept  phase  activity  to  determine 
system  needs 


Evolving  new  system-of-systems 
capability  by  leveraging  synergies  of 
legacy  systems 

Dynamic  reconfiguration  of  architecture  as 
needs  change;  use  of  service  oriented 
architecture  approach  as  enabler 

Component  systems  can  operate 
Independently  of  SoS  In  a  useful  manner 
Protocols  and  standards  essential  to 
enable  Interoperable  systems 

Added  “ilities’  such  as  Flexibility, 
Adaptability,  Composeability 

Component  systems  separately  acquired 
and  continue  to  be  managed  as 
independent  systems 


Intense  concept  phase  analysis  followed 
by  continuous  anticipation,  aided  by 
ongoing  experimentation 


Table  1.  SoS  Engineering  vs.  SE  differences 
(Erom;  Saunders,  2005) 

“SoS  Engineering  (SoSE)  is  an  emerging  interdisciplinary  approach  focusing  on 
the  effort  required  to  transform  capabilities  into  SoS  solutions  and  shape  the  requirements 
for  systems”  (SOSCE,  2008).  SoS  engineering  ensures  that: 
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•  Individually  developed,  managed,  and  operated  systems  funetion  as 
autonomous  eonstituents  of  one  or  more  SoSs,  and  provide  appropriate 
functional  capabilities  to  each  of  those  SoSs  (SOSCE,  2008). 

•  Political,  financial,  legal,  technical,  social,  operational,  and  organizational 
factors,  including  the  stakeholders’  perspectives  and  relationships,  are 
considered  in  SoS  development,  management,  and  operations 
(SOSCE,  2008). 

•  An  SoS  can  accommodate  changes  to  its  conceptual,  functional,  physical, 
and  temporal  boundaries  without  negative  impacts  on  its  management  and 
operations  (SOSCE,  2008). 

•  An  SoS  collective  behavior,  and  its  dynamic  interactions  with  its 
environment  to  adapt  and  respond,  enables  the  SoS  to  meet  or  exceed  the 
required  capability  (SOSCE,  2008). 

“SoS  Engineering  is  the  discipline  for  the  design,  development,  deployment, 
operation,  and  modifications  of  SoS”  (SOSCE,  2008).  In  particular,  SoS  Engineering 
addresses  the  challenges  involved  with  the  integration  of  independent  systems  with  a 
common  function.  “SoS  Engineering  spans  the  lifecycle  of  the  SoS,  potentially  meeting 
constituent  systems  through  different  phases  of  their  individual  lifecycles.  It  acts  on  the 
SoS  as  the  object  of  engineering  effort,  setting  the  environment  and  defining  relationships 
for  further  analysis  and  engineering  at  the  individual  system  level  for  constituents” 
(SOSCE,  2008). 

F.  SYSTEMS  OF  SYSTEMS  (SoS)  ARCHITECTING 

The  role  of  SoS  architecting  in  the  SE  process  is  to  integrate  functional 
architecture  within  the  functional  analysis/allocation  design  loop.  The  necessary 
architecting  paradigm  is  not  present  within  the  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE),  Defense  Acquisition  University  (DAU),  and  EIA-632  SE  processes. 

The  architecting  of  an  SoS  starts  with  the  transformation  of  an  operational 
capability  need  into  a  set  of  requirements,  which  are  used  to  guide  the  development  of 
functional  and  physical  architectures  through  design  (Whitcomb,  2008).  The 
development  of  functional  architectures  will  bridge  the  gap  between  the  stakeholders’ 
needs  and  an  understandable  functional  breakdown  structure  of  the 
collected  requirements. 
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G.  CAPABILITIES-BASED  SYSTEMS  DEVELOPMENT 

The  DoD  is  in  the  proeess  of  implementing  a  eapabilities-based  requirements-to- 
resources  system.  “This  transformation  of  the  requirements  generation  and  resoureing 
proeesses  holds  promise  for  delivering  more  warfighting  eapabilities  to  the  Combatant 
Commanders  in  a  resouree  eonstrained  environment”  (Walker,  2005). 

The  DoD  direeted  the  initiation  of  a  eapabilities-based  approaeh  to  defining 
defense  requirements  (Walker,  2005).  The  emphasis  was  plaeed  on  delivering 
eapabilities  to  address  a  wide  range  of  mission  objeetives  of  the  future  towing  and 
salvage  platform(s).  As  stated  by  Donald  Rumsfeld,  the  switch  to  eapabilities-based 
architecting  is  pertinent  in  achieving  the  future  mission  objectives  of  all  U.S. 
military  systems: 

A  central  objective  of  the  Quadrennial  Defense  Review  was  to  shift  the 
basis  of  defense  planning  from  a  ‘threat-based’  model  that  has  dominated 
thinking  in  the  past,  to  a  ‘eapabilities-based’  model  for  the  future.  This 
eapabilities-based  model  focuses  more  on  how  adversaries  fight,  rather 
than  specifically  whom  the  adversary  might  be  or  where  a  war  might 
occur.  It  recognizes  that  it  is  not  enough  to  plan  for  large  conventional 
wars  in  distant  theaters.  Instead,  the  United  States  must  identify  the 
capabilities  required  in  order  to  defeat  adversaries  who  will  rely  on 
surprise,  deception,  and  asymmetric  warfare  to  achieve  their  objectives 
(Rumsfeld,  2007). 

A  major  factor  that  could  inhibit  the  future  salvage  platform  from  meeting  its  full 
potential  is  that  the  proposed  top-level  characteristics  are  requirements  driven,  with  the 
initial  designer  having  a  preconceived  notion  of  the  solution.  The  method  of  developing 
systems  referred  to  by  Secretary  Rumsfeld,  as  well  as  the  new  systems  development 
process,  called  the  Joint  Capabilities  Integration  Development  System  (JCIDS),  is  shown 
in  Figure  4. 
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Figure  4.  New  Capabilities-Based  Acquisition  approach  (From;  Walker,  2005) 

The  left-hand  side  of  Figure  4  represents  a  simplified  version  of  the  old 
Requirements  Generation  System  that  Secretary  Rumsfeld  alluded  to  (Walker,  2005). 
The  old  method  concentrated  on  generating  requirements  in  order  to  fulfill  their  “idea”  of 
warfighting.  These  required  capabilities  were  derived  within  a  system  where  joint 
service  contributions  were  ignored.  The  new  capability-based  planning  approach  is 
represented  on  the  right-hand  side  of  Figure  4.  Instead  of  trying  to  generate  interservice 
requirements,  based  on  joint  service  capabilities,  at  the  end  of  the  process,  the  new 
approach  inverts  the  paradigm,  concentrating  on  the  capabilities  of  the  joint  services  at 
the  beginning  of  the  process  (Walker,  2005). 

The  use  of  capabilities-based  planning  has  proven  beneficial  to  certain  companies. 
Analogous  to  DoD’s  approach  to  generating  military  requirements,  represented  in 
Figure  4,  commercial  industries  that  have  determined  what  logistics  infrastructure 
capabilities  were  required,  compared  to  those  who  have  used  the  approach  of  generating 
requirements,  have  had  major  success  (Walker,  2005).  Identifying  processes  that  provide 
the  capability  needed  by  the  customer  can  be  identified  with  an  SoS  architecture 
framework  within  the  SE  process  model. 
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An  architecting  process  can  provide  the  capabilities  needed  by  pulling  the 
requirements  based  on  mission  need,  and  by  focusing  on  the  problem  rather  than  the 
solution.  Figure  5  identifies  a  set  of  problem  space  domains  that  must  be  addressed,  prior 
to  focusing  on  the  solution  space  or  the  generation  of  requirements.  The  problem  space 
identifies  the  functions  within  each  component  of  a  system.  The  functions  were  derived 
based  on  the  mission  need  and  CONOPS,  and  will  be  used  to  identify  the  capability  of 
the  system  needed  to  successfully  complete  that  mission. 


PROBLEM  SPACE 


SOLUTION  SPACE 


Figure  5.  Problem  and  Solution  Space  for  Systems  Architecting  and  Engineering 

(From:  IEEE,  2006) 

The  architecting  process  must  include  the  ability  to  allow  for  an  iterative 
process  of  discovery  in  meeting  emerging  capability  needs  as  they  arise. 
Implementation  of  this  capability-based  development  process  is  the  front- 
end  to  the  system  acquisition  and  development  process,  and  is  an  attempt 
to  provide  a  sound  basis  for  beginning  a  systems  engineering  approach  to 
development  by  keeping  the  early  stage  process  focused  on  the  problem 
space  and  not  the  solution  space  (Whitcomb,  2008). 

“A  Capabilities-Based  Assessment  (CBA)  is  conducted  to  identify  capability 
needs,  capability  gaps,  capability  excesses,  and  approaches  to  provide  needed  capabilities 
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within  a  specified  functional  or  operational  area”  (CJCSI  3170.01C,  2007).  According  to 
the  CJCSI  3 170. OIF  Glossary  (2007),  a  capability  need  is  defined  as  “a  capability  that  is 
required  to  be  able  to  perform  a  task  within  specified  conditions  to  a  required  level  of 
performance.”  A  capability  gap  is  what  results  from  the 


.  .  .  inability  to  achieve  a  desired  effect  under  specified  standards  and 
conditions  through  combinations  of  means  and  ways  to  perform  a  set  of 
tasks.  The  gap  may  be  the  result  of  no  existing  capability,  lack  of 
proficiency  or  sufficiency  in  existing  capability,  or  the  need  to  recapitalize 
an  existing  capability  (CJCS  Instruction  3I70-0IF  and  CJCS  Manual 
3170-01C,2007). 


The  JCIDS  is  one  component  of  the  capability-based  planning  (CBP)  process  that 
the  DoD  uses  as  its  principal  decision  support  process  for  transforming  the  military  to 
support  the  national  military  and  defense  strategy.  JCIDS  plays  a  key  role  in  identifying 
the  capabilities  required  by  the  warfighters  to  support  the  national  defense  strategy  and 
the  national  military  strategy.  The  procedures  established  in  the  JCIDS  identify,  assess, 
and  prioritize  joint  military  capability  needs  as  specified  in  Figure  6  (JCIDS,  2007). 
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Figure  6.  JCIDS  Methodology  with  Joint  Concept  Development  and  Revision  Plan 

(From;  Walker,  2005) 
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The  JCIDS  implements  a  eapabilities-based  methodology  that  “leverages  the 
expertise  of  all  government  ageneies  to  identify  improvements  to  existing  eapabilities  and 
to  develop  new  warfighting  eapabilities”  (CJCSI  3 170. OIF,  2007).  This  approaeh 
requires  a  eollaborative  proeess  that  utilizes  joint  eoneepts  and  integrated  arehiteetures  to 
identify  prioritized  eapability  gaps  and  integrated  poliey  approaehes  to  resolve  those  gaps 
(JCIDS,  2007). 

The  evolving  Joint  Coneept  Development  and  Revision  Plan  identified  in  Figure  6 
is  “a  deseription  of  how  a  Joint  Foree  Commander  10-20  years  in  the  future  will  integrate 
eapabilities  to  generate  effeets  and  aehieve  an  objeetive”  (Walker,  2005).  Onee  the 
required  capabilities  (what  we  want  to  be  able  to  do)  are  identified,  the  JCIDS  process  is 
intended  to  assess  our  capacity  to  fulfill  those  capabilities. 

Systems  architecting  and  SE  present  complementary  approaches  to  the 
development  of  an  SoS.  For  capability-based  development  of  unprecedented  systems,  the 
initial  portions  of  the  traditional  SE  process  have  been  demonstrated  to  show 
unsatisfactory  results,  in  particular  due  to  the  complexity  in  transforming  ill-defined 
capabilities  into  requirements  useful  enough  to  begin  any  engineering-based  design.  A 
capability  is  defined  as  “the  ability  to  achieve  a  desired  effect  under  specified  standards 
and  conditions  through  combinations  of  means  and  ways  to  perform  a  set  of  tasks” 
(IEEE,  2006).  “Capabilities,  often  referred  to  as  operational  scenarios,  consist  of  a 
sequence  of  operational  activities  needed  to  respond  to  or  to  provide  an  external 
stimulus”  (Whitcomb,  2008).  Eigure  7  displays  the  typical  SE  process,  with  the 
eapabilities-based  development  process  incorporated  to  include  a  capability  pull  feedback 
loop.  This  will  ensure  customer  capability  needs  are  continuously  being  addressed  and 
revised  throughout  the  SE  process. 

While  recognition  of  focus  on  capabilities-driven  systems 
architecting  has  given  rise  to  the  fairly  recent  development  of  system 
architecting  methods,  frameworks,  and  processes,  what  is  lacking  at  this 
time  is  a  defined  method  for  architecting — the  development  of  the 
architecture  itself  (Whitcomb,  2008). 
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Figure  7.  Capabilities-based  SE  process  (From;  Whitcomb,  2008) 

The  outcome  of  this  process  is  the  fundamental  description  of  the  basis  for  the 
system — its  architecture.  This  architecture  defines  the  elements,  their  relationships,  and 
the  principles  guiding  its  design  and  evolution.  This  architecture  must  be  made  visible  to 
all  system  stakeholders,  since  it  is  the  first  embodiment  of  the  system  that  can  be 
reasoned  about.  This  is  accomplished  through  frameworks. 

H.  ARCHITECTURE  FRAMEWORKS 

It  is  typical  for  engineers  to  treat  the  development  of  systems  similar  to  the 
development  of  more  basic  commercial  consumer  products — by  attempting  to  describe 
the  total  system  down  to  the  individual  component.  Without  putting  tight  bounds  on  the 
engineering  task,  the  engineer  would  develop  descriptive  information  that  would  keep 
expanding  toward  the  total  system  description.  In  a  systems  architecting  approach,  the 
development  of  the  architecture  takes  the  place  of  the  description  of  components.  There 
now  exists  a  need  to  be  able  to  articulate  the  relationships  of  the  elements  of  the 
architecture,  and  this  is  done  through  architecture  views  in  frameworks. 


18 


The  architectural  views  of  a  framework  set  well-defined 
boundaries  for  a  given  aspect  of  the  system  while  reassuring  the 
engineering  team  that  the  full  architectural  description  will  serve  to 
describe  the  system  in  full.  The  use  of  frameworks  provides  a  comfortable 
environment  for  the  systems  team  to  conquer  the  complex  system 
(Richards  et  ah,  2007). 

The  large  amount  of  information  associated  with  an  architecture  is  best 
considered  within  a  structure  or  framework,  in  which  it  can  be  interrelated,  manipulated, 
and  displayed.  Architecture  frameworks  are  tools  for  coping  with  system  complexity  by 
structuring  data  into  views  with  a  common  language,  and  are  used  to  provide  a  consistent 
documentation  basis  to  describe  a  system’s  characteristics  (DoDAF,  2007).  The 
Department  of  Defense  Architecture  Framework  (DoDAF)  is  the  standard  systems 
architecture  used  within  the  United  States  military.  DoDAF  version  1.5,  published  in 
April  2007,  is  the  current  architecture  framework  guidance,  with  version  2.0  to  be 
released  soon  (DoDAF,  2007). 

The  Zachman  framework,  originated  by  John  Zachman,  is  considered  canonical, 
as  it  set  the  standard  for  a  philosophy  for  classifying  a  system  architecture.  The  intent  of 
the  Zachman  framework  is  to  establish  a  common  vocabulary  that  defines  complex 
enterprise  systems.  The  Zachman  framework  classifies  and  organizes  the  design  artifacts 
created  in  the  process  of  designing  and  producing  complex  systems  (Sessions,  2007). 
The  Zachman  institute  developed  a  framework  design  to  capture  the  nuances  of  enterprise 
architecting  displayed  in  Figure  7. 

It  uses  a  two  dimensional  classification  model  based  on  the  six  basic 
interrogatives  (What,  How,  Where,  Who,  When,  and  Why)  intersecting  six 
distinct  perspectives,  which  relate  to  stakeholder  groups  (Planner,  Owner, 
Designer,  Builder,  Implementer  and  Worker).  The  intersecting  cells  of  the 
Framework  correspond  to  models  which,  if  documented,  can  provide  a 
holistic  view  of  the  enterprise  (Sessions,  2007). 
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Figure  8.  Zachman  Framework  for  Enterprise  Arehitecture  (From;  ZIFA,  2008) 


All  DoD  weapons  and  information  technology  system  procurements  are  required 
to  develop  and  document  a  systems  architecture  using  the  views  prescribed  in  the 
DoDAF  (AFF,  2008).  The  DoDAF  was  originally  designed  based  on  the  Zachman 
framework  and  is  suited  to  organize  large  systems  with  complex  integration  and 
interoperability  challenges.  Similar  architecture  frameworks  are  the  Ministry  of  Defence 
(United  Kingdom)  Architecture  Framework  (MODAF),  the  Canadian  Forces  (CF) 
Architecture  Framework  (DNDAF).  Along  with  the  DoDAF,  the  MODAF  and  DNDAF 
are  organized  around  a  shared  repository  to  hold  work  products  (AFF,  2008). 

“The  overall  objective  of  architecture  frameworks  is  to  improve  the  ability  of  the 
system  acquirer,  builder,  and  user  to  make  technical  decisions”  (Richards  et  ah,  2007). 
The  motivation  for  the  development  of  an  architecture  framework  was  the  desire  to 

capture  systems  information  in  a  manner  that  enriched  the  overall  system  description. 
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Architecture  frameworks  are  further  evolutions  of  this  essential  need  to  develop  system 
descriptions  that  are  complete,  correct,  coherent,  and  usable  for  multiple  stakeholders  in 
the  development  of  systems  (Richards  et  ah,  2007).  DoDAF  version  1.5  is  a  descriptive 
methodology  for  capturing  high-level  system  information  using  three  views;  Operational 
View  (OV),  Systems  View  (SV),  and  Technical  Standards  View  (TV).  An  additional 
view,  the  All  View  (AV)  (introduced  in  version  1.5),  is  an  overview  and  summary 
document  of  the  architecture. 

The  relationship  of  architectural  products  of  a  capabilities-based  acquisition 
process  is  shown  in  Figure  9  (Biggs,  2005).  This  MODAF  diagram  can  also  be  found  in 
similar  form  in  the  DoDAF  and  DNDAF  documents,  which,  in  turn,  were  developed  from 
the  Zachman  framework  (ZIFA,  2008).  The  chief  difference  between  the  MODAF  and 
the  DoDAF  is  the  inclusion  of  the  Strategic  View  (StV)  in  the  MODAF.  This  is 
important,  as  the  StV  captures  the  capability  view  (Whitcomb,  2008). 


Figure  9.  MODAF  Relationships  for  Acquisition  Processes  (MODAF,  2006) 

The  DoDAF,  MODAF,  and  DNDAF  define  a  common  approach  for  architectural 
description,  development,  presentation,  and  integration  (Huynh  &  Osmundson,  2007). 
Recent  evidence  collected  by  the  DoD  suggests  that  there  is  a  gap  between  the  intended 
use  of  architecture  frameworks  in  acquisition  and  their  deployment  in  industry 
(OASDNII,  2005).  For  example,  the  Joint  Net-Centric  Operations  (JNO)  end-to-end 
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delivery  is  currently  suboptimally  managed  to  provide  a  synchronized,  timely,  integrated, 
and  cost-effective  capability.  System  integration  management,  using  enterprise 
architecture,  requires  a  unified  set  of  architectural  standards  in  order  to  maintain  a 
synchronized  interoperability.  The  JNO  intends  to  use  a  capabilities-based  architecture 
management  approach  to  deliver  timely,  end-to-end,  integrated  capability  to  the 
warfighter  (OASDNII,  2005).  The  DoDAF  repository  is  defined  by  the  Core  Architecture 
Data  Model  (CADM),  which  will  be  described  further  in  Chapter  IV  and  will  be  used  to 
model  the  capability  needs  of  the  future  salvage  platform  for  the  replacement  of  the  ARS 
50  and  T-ATF  166. 

I,  DEPARTMENT  OF  DEFENSE  ARCHITECTURE  FRAMEWORK 

(DoDAF)  VERSION  1.5  VIEW  DESCRIPTIONS 

The  DoDAF  organizes  components  of  a  systems  architecture  into  corresponding 
views.  This  method  of  system  architecture  is  well  suited  to  organizing  large  systems  with 
interoperability  challenges,  and  is  unique  in  its  use  of  “operational  views”  detailing  the 
external  customer’s  operating  domain,  in  which  the  developing  system  will  operate 
(Zachman,  2007).  DoDAF  is  organized  into  four  view  sets: 

•  The  AV  provides  an  overarching  capture  of  the  scope  and  context  of  the 
entire  architecture,  without  focusing  on  a  distinct  view  of  the  architecture. 
The  scope  and  context  of  the  architecture  would  define  the  interconnected 
settings  of  the  architecture,  including  the  subject  area  and  time  frame  for 
the  architecture.  These  settings  would  include  techniques,  procedures, 
and  CONOPS. 

•  The  OV  provides  a  description  of  the  operational  tasks  and  activities 
required  to  accomplish  the  mission.  It  also  provides  schematic 
representations  of  operational  nodes  and  the  information  flow 
between  them. 

•  The  SV  describes  systems  and  interconnections  between  architectural 
components  to  the  OV,  which  support  organizations  and  their  operations. 

•  The  TV  defines  the  technical  standards  that  administer  the  system 
architecture,  on  which  engineering  specifications  are  based.  Its  purpose  is 
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to  ensure  that  a  system  satisfies  its  operational  requirements,  including 
policies  and  standards  that  govern  the  system  being  architected.  TV 
delineates  the  technical  implementation  criteria  to  which  the  system  or 
SoS  should  comply.  The  DoDAF  explains  TV  as  a  way  to  promote 
efficiency  and  interoperability  (DoDAF,  2004). 

Figure  19  displays  the  architectural  view  descriptions  and  their  interrelationships, 
“providing  the  basis  for  deriving  measures  such  as  interoperability  or  performance,  and 
for  measuring  the  impact  of  the  values  of  these  metrics  on  operational  mission  and  task 
effectiveness”  (DoDAF,  2007). 
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Figure  10.  Linkages  Among  the  AVs  (From;  DoDAF,  2007) 

Multiple  architectural  “views”  are  created  to  ensure  that  stakeholders’  concerns 
are  addressed.  The  architecture  is  defined  through  this  series  of  views,  each  depicting  the 
architecture  with  respect  to  each  stakeholder’s  perspective,  such  that  it  is  clear  that  their 
needs  are  addressed.  All  views  are  derived  from  a  single  system,  or  SoS,  architecture, 
with  each  view  being  derived  from  a  common  set  of  architectural  relationships. 
Architecture  exists  for  the  purpose  of  achieving  a  well-defined  system  in  both  operational 
and  physical  domains,  such  that  the  eventual  system  developed  from  the  architecture  can 
be  used  to  meet  desired  operational  capabilities. 
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J.  NAVAL  ARCHITECTURE  ELEMENTS  REFERENCE  GUIDE 

Architecture  implementation  is  best  organized  around  standard  semanties  and 
referenee  terminology  (Ring,  2001).  “Every  architecture  should  be  constructed  from 
common  terms,  forming  the  elemental  building  blocks  of  the  arehitecture,  standardizing 
arehiteetural  elements”  (Naval  Arehitecture  Elements  Referenee  Guide,  December  2007). 

“Architecture  elements  represent  the  critieal  taxonomies,  requiring  concurrence 
and  standardization  for  an  integrated  arehitecture  as  deseribed  by  the  DoDAE”  (Siel, 
2007).  They  contain  the  dietion  for  the  arehiteetural  views  and  are  used  to  ensure  a 
eonsistent  integration  of  systems  within  an  SoS  arehitecture.  “The  data  contained  in  the 
Navy  Architecture  Element  Referenee  Guide  (NAERG)  shall  be  used  for  overall 
architeeture  framework  development,  programmatie  researeh,  development,  and 
aequisition  aetivities,  and  related  integration  and  interoperability  and  eapability 
assessments”  (Siel,  2007). 

The  Supervisor  of  Salvage  (SUPSALV)  SoS  enterprise  will  be  described  in  terms 
of  the  NAERG  elements,  in  order  to  explicitly  define  the  architecture.  The  SUPSALV 
NAERG  elements  are  organized  into  the  following  lists: 

•  Common  System  Eunction  List  (CSEL) 

•  Common  Operational  Activities  List  (COAL) 

•  Common  Information  Element  List  (CIEL) 

•  Common  Operational  Nodes  List  (CONE) 

•  Common  Systems  Nodes  List  (CSNL) 

•  Common  Systems  List  (CSL) 

K.  CONCLUSION 

This  ehapter  summarizes  many  aspeets  related  to  the  development  of  a 
capabilities-driven  MBSE  process  that  direetly  addresses  the  development  of  the 
arehiteeture  as  the  fundamental  basis  of  the  systems  definition.  The  process  of 
identifying  capability  needs,  analyzing  system  functions,  and  allocation  to  system 
physieal  components  eannot  eurrently  be  satisfactorily  completed  given  existing 
architeeture  framework  products  alone.  Chapter  II  deseribes  the  baekground  for  the 
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towing  and  salvage  capability  need,  Chapter  III  describes  the  development  of  a  design 
reference  mission  (DRM)  for  use  in  mapping  mission  activities  to  system  functions, 
chapter  IV  describes  the  model-based  method  for  creating  the  towing  and  salvage 
architecture.  Chapter  V  discusses  architecture  results  and  chapter  VI  summarizes 
conclusions  and  recommendations. 
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II.  UNITED  STATES  NAVY  SALVAGE  COMMUNITY 


A.  INTRODUCTION 

The  Salvage  Faeilities  Act  (10  U.S.C.  7361-764)  authorizes  the  Secretary  of  the 
Navy  to  have  a  salvage  program.  It  allows  for  the  maintenance  of  a  national  salvage 
capability  for  use  in  peacetime,  war,  or  national  emergency  (OPNAVINST  4740. 2G, 
2007).  Salvage  forces  have  unique  tasks,  which  require  specialized  equipment  and  highly 
trained  personnel.  The  “triad”  of  U.S.  Navy  salvage  forces  integrates  the  Mobile  Diving 
and  Salvage  Unit  (MDSU),  Military  Sealift  Command  (MSC),  and  the  Supervisor  of 
Salvage  and  Diving  (SUPALV,  NAVSEA  OOC),  and  serves  as  the  core  for  removing 
hazards  of  navigation  (in  foreign  and  domestic  coastal  waters),  repair  and  towing 
damaged  vessels,  recovery  of  sensitive  items  (such  as  aircraft  black  boxes),  and  recovery 
of  other  high-value  objects  from  the  ocean  depths. 

In  1999,  Navy  salvage  assets  were  involved  in  a  number  of  high-pro fde  salvage 
events,  such  as  the  salvage  of  Swiss  Air  flight  1 1 1,  the  John  F.  Kennedy,  Jr.  search-and- 
recovery  operation,  and  the  salvage  of  a  crashed-by-suicide  Air  Egypt  flight.  In  that  year, 
the  only  outsourced  salvage  event  was  the  salvage  of  an  SH-60  in  the  Arabian  Gulf  by 
the  Fraser  Company.  Navy  salvage  ships  were  also  busy  in  2000,  with  the  Air  Alaska 
tragedy.  These  are  a  few  examples  of  the  tasks  completed  by  these  organic  forces  within 
the  Department  of  the  Navy. 

Although  each  functional  element  of  the  salvage  triad  works  jointly  for  both 
salvage  and  towing;  each  has  a  separate  organizational  structure.  SUPSAEV  is  an  agency 
(Code  OOC)  of  Naval  Sea  Systems  Command  (NAVSEA),  which  is  not  in  the  operational 
chain  of  command.  For  salvage  operations  directed  by  the  Chief  of  Naval  Operations, 
SUPSAEV  is  tasked  as  operational  control.  Furthermore,  SUPSAEV  is  the  technical 
authority  for  all  U.S.  Navy  diving  operations  and  authorizes  any  equipment  used.  When 
personnel  or  equipment  assets  are  not  available,  SUPSAEV  maintains  and  exercises  all 
diving  and  salvage  contracts.  For  deep  ocean  recovery  and  emergent  ship  salvage 
material,  SUPSAEV  maintains  and  exercises  government-owned,  contractor-operated 
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(GO-CO)  equipment  and  capabilities  to  provide  recovery  of  objects  to  a  depth  of  at  least 
20,000  feet,  ship  salvage,  pollution  control,  and  underwater  ship  husbandry. 

MDSU  One  and  MDSU  Two  are  components  of  the  Naval  Expeditionary  Combat 
Command.  Their  mission  is  to  provide  a  combat-ready,  deployable  detachment  to 
conduct  harbor  clearance,  salvage,  underwater  search  and  recovery,  and  underwater 
emergency  repairs.  They  are  equipped  with  diving  and  salvage  equipment  that  is 
air-mobile  and  scalable  to  mission  objectives.  The  detachment  can  be  as  small  as  five 
divers  for  small  operations  such  as  side-scan  sonar  search  missions  to  larger  groups  for 
larger  salvage  operations.  MDSU  units  work  with  NAVSEA  as  separate  Operational 
Activities  and  as  a  resource  for  shallow-water  salvage  missions. 

Currently,  the  ocean-towing  ships  are  manned  with  operating  crews  of  civil 
service  mariners  (CivMars).  In  the  civilian  crewing  construct.  Navy  salvors  are 
embarked  as  needed  to  perform  the  various  diving  or  salvage  operations.  The  salvage 
ships  are  currently  being  converted  to  civilian  manning.  Eor  the  foreseeable  future,  the 
Navy  plans  to  maintain  four  salvage  ships  and  four  ocean-towing  ships,  all  manned  by 
CivMars.  CivMars  differ  from  commercial  civilian  mariners  in  one  key  aspect:  they  can 
be  reliably  controlled  and  are  dependable  under  combat  conditions.  This  distinction  is 
recognized  within  the  MSC  (Sperling  &  Keenan,  2006). 

The  collaboration  with  the  MSC  enables  the  Navy  to  provide  salvage  and  towing 
capabilities.  The  MSC’s  mission  is  to  provide  combat  logistics  to  sustain  United  States 
forces  worldwide  during  peacetime  and  in  war,  for  as  long  as  operational  requirements 
dictate.  Administratively,  MSC  is  a  Navy  Echelon  III  command  under  United  States 
Elect  Eorces  (USEE),  providing  more  than  40  government-owned  and  government- 
operated  (GO-GO)  ships.  Operationally,  MSC  is  the  Navy  Component  Commander  to 
the  United  States  Transportation  Command  (USTRANSCOM)  and  supports  mission 
objectives  through  Sealift  Eogistics  Commanders  (SEALOGS).  An  Echelon  IV 
command — Military  Sealift  Elect  Support  Command  (MSESC) — was  formed  in 
October  2006  to  man,  train,  equip,  and  maintain  GO-GO  ships.  The  ARS  and  T-ATE 
ships  are  part  of  the  Type  Command  (TYCOM)  under  the  MSESC  and  are  manned  by 


28 


CivMars.  Performing  TYCOM  Commander  duties  makes  MSFSC  the  only  subordinate 
eommand  under  MSC  with  global  responsibilities  (COMSCINST  3191.9B,  2007). 

B,  SEA  OOC 

The  Offiee  of  the  Direetor  of  Oeean  Engineering,  Supervisor  of 
Salvage  and  Diving  (SUPSALV),  or  OOC  as  it  is  known  in  the  Fleet,  is  part 
of  the  Naval  Sea  Systems  Command.  SUPSALV  is  loeated  in  the 
Washington  Navy  Yard  in  Washington,  DC.  SUPSALV  is  responsible  for 
all  aspeets  of  oeean  engineering,  ineluding  salvage,  in-water  ship  repair, 
eontraeting,  towing,  diving  safety,  and  equipment  maintenanee  and 
proeurement  (SUPSALV,  2008). 

The  OOCl  Business  Management  braneh  is  eomposed  of  a  Logisties  braneh,  a 
Proeurement  braneh,  and  a  Finanees  braneh.  The  Logisties  braneh  is  responsible  for  the 
management  and  support  of  logisties,  teehnieal  manuals,  data  management,  and  OOC- 
speeifie  inventory  eontrol.  Its  responsibilities  inelude: 

•  managing  the  logisties  requirements  and  resourees  at  minimal  eosts; 

•  managing  the  preparation  and  printing  of  equipment  and  proeedures 
manuals; 

•  ereating  data  paekages  that  support  eontraets;  and 

•  management  of  the  following  inventories:  Arehives,  Controlled  Reeords, 
and  Library. 

The  OOCl  Proeurement  braneh  is  responsible  for  managing  the  eontraets  that 
support  all  salvage.  Underwater  Ships  Husbandry  (UWSH),  pollution  response,  and 
undersea  operations.  Current  SEA  OOC  eontraets  inelude  (SUPSALV,  2008): 

•  The  Emergeney  Ship  Salvage  Material  (ESSM)  Contraet. 

•  The  Oil  Pollution  Abatement  Contraet. 

•  The  Hull  Cleaning  Serviees  Contraet. 

•  The  Western  Paeifie  Salvage  Contraet,  whieh  ineludes  all  salvage  tasking 
in  the  Western  Paeifie  Region. 

•  The  West  Coast  Salvage  Contraet,  whieh  ineludes  all  salvage  tasks  from 
the  Western  Coast  of  the  United  States  out  to  the  International  Date  Line. 
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•  The  East  Coast  Salvage  Contract,  which  includes  all  salvage  tasks  on  the 
Eastern  Coast  of  the  United  States,  North  and  South  Atlantic  Oceans,  and 
the  Mediterranean  Sea. 

•  The  Undersea  Operations  Contract. 

•  The  Diving  Services  Contract. 

The  OOCl  Einancial  branch  is  responsible  for  all  budgetary  and  financial 
management  functions  for  SEA  OOC-appropriated  funds  and  all  customer  funding. 
Responsibilities  include  receiving,  obligating,  tracking,  deobligating,  and  returning 
unused  operational  funds  (SUPSALV,  2008). 

The  00C2  Salvage  Operations  branch  maintains  the  commercial  contracts  for 
salvage,  emergency  towing,  deep  ocean  search-and-recovery  operations,  and  oil  pollution 
abatement  (SUPSAEV,  2008),  and  provides  salvage  technical  assistance  to  Elect  salvors 
and  other  federal  agencies.  00C2  owns,  maintains,  and  operates  the  following  programs: 

•  The  ESSM  system  manages  a  worldwide  network  of  warehouses,  wherein 
an  inventory  of  salvage  and  pollution  abatement  equipment  is  stored 
and  maintained. 

•  Deep  ocean  search  and  Remote  Operating  Vehicle  (ROV)  recovery 
systems,  with  depth  capabilities  up  to  20,000  feet  (ft).  The  00C2  ocean 
search-and-recovery  assets  include: 

—  Cable  Controlled  Underwater  Vehicle  (CURV)  III  ROV. 

—  Deep  Drone  7200  ROV. 

—  Magnum  ROV. 

—  MINIROVs. 

—  Orion  Search  System. 

—  Shallow  Water  Intermediate  Search  System  (SWISS). 

•  Emergency  salvage  response  to  operations  involving  strandings, 
collisions,  fires,  and  engineering  casualties  with  civilian  contractors  under 
direction  of  Navy  salvage  specialists  (SUPSALV,  2008).  The  00C2 
salvage  assets  include: 
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—  ARS  50  Salvage  Ships 

—  T-ATF  166  Towing  Ships 

•  Program  of  Ship  Salvage  Engineering  (POSSE)  provides  salvage  teehnieal 
assistanee  to  evaluate  struetural  integrity,  stability,  and  all  other 
engineering  aspeets  of  salvage  operations,  using  eomputerized  modeling 
and  eomputations. 

SEA  00C25  Pollution  Support  is  SLIPS AEV’s  worldwide  pollution  response 
division.  The  division  is  made  up  of  several  branehes  including  pollution  equipment, 
pollution  training,  pollution  response,  pollution  research  and  development,  pollution 
planning  and  compliance,  and  pollution  logistics  support.  Pollution  logistics  support  is 
accomplished  through  a  sophisticated  support  system  that  utilizes  both  the  military  cargo 
transport  system  and  the  commercial  transport  system. 

SEA  00C3  Diving  Program  is  the  Navy’s  and  DoD’s  diving  technical  authority. 
00C3  Diving  provides  service  for  diving  equipment,  policies,  and  procedures  from  basic 
research  through  prototype  development,  acquisition/publication,  and  life-cycle 
management.  It  oversees  the  acquisition  of  initial  Elect  outfitting  and  life-cycle 
management  of  equipment,  technical  manuals,  instructions,  and  PMS.  Additionally,  it 
provides  direct  Elect  support  for  technical  issues,  which  includes  diving  advisories, 
diver’s  feedback  form,  and  support  contacts. 

SEA  00C4  Certification  division  is  the  System  Certification  Authority  (SCA)  for 
the  U.S.  Navy  Diving  Program.  It  provides  an  objective  review  of  the  design, 
fabrication,  testing,  and  operating  and  maintenance  procedures  of  all  U.S.  Navy-owned  or 
-operated  manned  diving  and  hyperbaric  systems.  The  Certification  division  consists  of 
three  systems  engineers,  three  certification  technicians,  an  administrative  assistant,  and 
the  SCA.  The  Certification  division  performs  a  multitude  of  functions  in  assessing  the 
safety  of  system  designs  and  hardware.  During  the  system  design  phase,  these  functions 
include  the  review  of  design  calculations,  hazard  analyses,  material  compatibility,  system 
drawings,  and  quality  assurance  processes.  During  system  fabrication  and  testing, 
certification  personnel  review  procedures  and  records  to  ensure  that  the  system  hardware 
is  in  compliance  with  the  design  requirements.  After  initial  system  certification. 
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certification  personnel  conduct  periodic  surveys  of  previously  certified  systems  to  ensure 
that  they  are  maintained  in  a  safe  operating  condition.  This  division  is  also  responsible 
for  publishing  certification-related  technical  manuals  and  instructions  (SUPSALV,  2008). 

SEA  00C5  is  NAVSEA’s  Elnderwater  Ships  Husbandry  division.  It  develops 
techniques,  procedures,  and  equipment  to  perform  waterborne  ship  repairs  and  often 
eliminates  the  need  for  drydock  repairs,  which  extends  the  interval  between  drydockings 
and  minimizes  the  amount  of  ship  time  spent  in  dry  dock.  The  objectives  of  the  EIWSH 
Program  are  to  reduce  maintenance  costs,  while  improving  Elect  readiness.  The  UWSH 
division  uses  technical  experts  as  on-site  field  operators  to  provide  training  and  expertise 
to  Elect  maintenance  activities  worldwide  (SUPSAEV,  2008). 

C.  TOWING  AND  SALVAGE  PLATFORMS 

Towing  and  salvage  assets  of  the  Navy  perform  a  wide  variety  of  services  in 
peacetime  and  in  wartime.  Among  these  are;  ocean-towing  support  to  a  variety  of  Elect 
operations  in  forward  areas  and  support  for  the  training  of  Navy  salvors  and  divers;  high 
visibility  recovery  of  aircraft,  spacecraft,  stranded  ships,  and  barges;  routine  recovery  of 
lost  aircraft  and  weapons;  and  post-tsunami,  post-hurricane,  and  post-flooding  port 
clearance.  Navy  ocean- towing  and  salvage  ships  are  designed  with  these  functions  in 
mind.  Consequently,  they  should  be  high-powered  towing  ships  with  massive  off-ship 
firefighting  capability,  and  manned  with  sufficiently  trained  and  skilled  rescue  personnel 
to  aid  an  injured  ship  (Sperling  &  Keenan,  2006). 

Primary  Navy  combat  salvage  functions  include  minimizing  and  arresting 
damage,  and  safely  removing  damaged  combatants  from  an  engagement  so  the  ships  can 
be  repaired  and  returned  to  action.  Salvage  ships  can  perform  as  towing  platforms,  but 
the  primary  missions  are  to  perform  combat  salvage,  emergency  repair,  and  firefighting. 
Many  of  the  attributes  that  make  salvage  ships  good  salvage  and  towing  platforms,  also 
make  them  good  platforms  for  performing  these  ocean  engineering  operations; 
incorporating  everything  into  multifunctional  platforms  with  increasing  complexity  and 
cost.  Existing  Navy  salvage  ships,  as  shown  in  Eigure  10,  are  designed  to  accomplish  all 
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missions  simultaneously.  As  such,  there  are  a  number  of  design  compromises  that 
decrease  the  ability  to  optimally  perform  the  variant  combat  salvage  missions  (Sperling  & 
Keenan,  2006). 


Figure  1 1 .  ARS  Safeguard  class  (From;  SUPSALV,  2008) 


The  main  mission  for  the  ARS  class  is  diving  and  salvage.  The  diver’s  life 
support  system  is  integrated  into  the  ship  and  is  capable  of  supporting  up  to  six  divers 
through  its  consoles.  It  also  has  a  fixed  decompression  chamber.  The  system  has 
primary  300  pounds  per  square  inch  (psi)  medium  pressure  air  and  SOOOpsi  high  pressure 
secondary  air.  At  the  forward  part  of  the  fantail  there  are  diver’s  davits  for  lowering  and 
raising  a  diver’s  stage.  Additionally,  a  300psi  tunneling  manifold  is  available  on  the  port 
side  of  the  fantail  for  tunneling  under  large  objects  on  the  ocean  floor  (SS500-AM- 
MMO-010,  2007).  A  detachment  of  MDSU  sailors  augment  the  crew  for  deployment 
and  emergent  salvage  operations.  MDSU  sailors  also  supplement  the  ATF  MSFSC  crew 
for  missions.  The  ATF  class  ship  does  not  have  any  diver’s  life  support  systems 
integrated;  it  must  be  brought  onboard  by  the  MDSU  detachment.  The  ARS  is  255  ft 
long  and  52  ft  wide,  has  a  depth  of  28  ft,  draws  17  ft,  and  displaces  3,282  tons.  Powered 
by  four  high-speed  diesel  engines — twin  shaft  with  controllable  pitch  props  (two  fixed 
nozzles)  for  a  total  of  4,200  shp — it  has  a  bollard  pull  of  68  tons  and  maximum  speed  of 
14  kts. 
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In  wartime,  there  is  a  relationship  between  the  salvage  ships  and  the  oeean-towing 
ships  of  the  Navy.  Often  during  intensive  battle  operations,  combatants  that  have  been 
stabilized  by  a  salvage  ship  can  be  towed  to  safety  by  a  towing  ship,  while  the  salvage 
ship  reaches  out  for  another  wounded  combatant  or  is  engaged  in  other  combat  salvage 
operations  (Sperling  &  Keenan,  2006).  Both  classes  of  ships  can  perform  ocean-going 
towing  services  such  as  towing  ships,  barges,  and  targets  for  gunnery  exercises.  The 
Navy’s  towing  effort  is  limited  to  ocean  towing,  rescue  towing,  and  salvage  towing. 
Ocean  towing  is  defined  as  point-to-point  (from  one  harbor  to  another)  towing  with  no 
refuge  en  route.  This  includes  the  safe  towing  of  defueled  nuclear  powered  ships. 
Rescue  towing  is  the  saving  a  stricken  or  inoperable  ship  at  sea  and  towing  to  safe  harbor. 
Salvage  towing  ships,  as  shown  in  Figure  12,  involve  the  immediate  towing  of  a  vessel 
after  a  salvage  operation.  Combat  salvage  and  towing  missions  involve  service  in  hostile 
areas,  where  vessels  are  damaged,  afire,  disabled,  or  stranded  due  to  enemy  fire 
(TOWMAN,  1998). 


Figure  12.  T-ATF  Powhatan  class  (From;  SUPSALV,  2007) 

Ocean  towing  ships  are  larger  and  more  powerful  than  harbor-  or  coastal-towing 
craft.  The  current  class  of  Navy  towing  ships,  the  T-ATF,  is  a  derivative  design  from  the 
resupply  boat  used  in  the  offshore  oil  exploration  industry.  It  is  226  ft  long  and  42  ft 
wide,  has  a  depth  of  18  ft,  draws  15  ft,  and  displaces  2,260  tons.  Powered  by  two 
medium-speed  diesel  engines — twin  shaft  with  controllable  pitch  props  (two  fixed 
nozzles)  for  a  total  of  7,200  shp — it  has  a  bollard  pull  of  87.5  tons  and  maximum  speed 
of  15  kts.  Designed  as  a  towing  ship,  it  has  a  towing  winch  and  an  automatic  towing 
machine.  It  also  has  space  for  20  passengers.  When  a  diving  detachment  is  embarked 
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with  equipment,  as  when  performing  forward  area  salvage  operations,  the  containerized 
decompression  chamber  and  other  diving  equipment,  positioned  on  the  after  deck,  blocks 
the  ability  to  tow  (Sperling  &  Keenan,  2006). 

D,  PLATFORM  CHARACTERISTICS 

Navy  salvage  ships  are  outfitted  with  sufficient  salvage  requirements  to  permit  the 
salvage  and  towing  ships  to  remove  and/or  float  a  stranded  Navy  ship  operating  in 
uncharted  waters,  close  to  hostile  shores.  Table  2  displays  the  major  desirable 
characteristics  of  a  future  towing/salvage  ship  (labeled  MSC  PMl)  and  also  shows  the 
characteristics  of  the  current  towing  and  salvage  ships  of  the  Navy,  as  well  as  the  general 
characteristics  of  a  large  commercial  ocean  rescue  ship  (Sperling  &  Keenan,  2006). 


CharactQristics 

TATF 

TARS 

ComnyP 

MSC  PM  1 

Class 

ABS  Class  C 
ice-strengthen¬ 
ing. 

1  compartment 
DC  criteria 

ABS  Cl  ass  C 
ice-strengthen- 

2  compart¬ 
ment  DC  ciite- 
ria 

Llovds+I  OOAI 
Tug+L.S4C 

ABS  Class  A 
ice-strengthen¬ 
ing. 

1  compatt- 
ment  DC  ciite- 
ria 

Length 

226  ft 

255  ft 

307  ft 

270  10  2  60  ft 

Breadth 

42  ft 

52  ft 

51  ft 

5  5  to  60  ft 

Depth 

20  Ft 

laft 

26  ft 

1ato20  Ft 

Displacement 

2,260  tons 

6,202  tons 

4,647  tons 

TBD 

Propulsion 

Power 

7,200  shp 

4,200  shp 

2  5,500  shp 

®  12,000  shp 
or  more 

Bollard  Pull 

67.5  tons 

6a  tons 

200  tons 

1 40  tons 

Table  2.  Major  desirable  characteristics  of  a  future  towing/salvage  ship 

(From:  Sperling  &  Keenan,  2006) 

Much  of  the  capability  of  a  towing  or  salvage  ship  is  in  the  equipment  and  outfit 
of  the  ship.  Tables  3  and  4  summarize  the  equipage  of  the  four  classes  displayed  in  Table 
1  (Sperling  &  Keenan,  2006). 
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Features 

T.ATF 

TARS 

lohn  Ross 

MSC  PMI 

Pumping 

W/O ESSM 

Icod  2,500 
gpni 

1 4,000gpm 

1 4,000  gpm 

TBD 

Electric  Power 
i.Overbcord.t 

1,200  kw,  440 
V.AC 

750  kw,  450 
VAC 

1,500  kw  440 
VAC 

TBD 

Compressed 

.Air 

6  flask  HP  air 
bank 

2-200  cfm 
compressors,  + 

1  portable  125 
cfm  compres¬ 
sor 

2-  570  cfm 
compress<:rs 
+2  portable 

450  dm  ccm- 
press<ors 

TBD 

Cut -ship  tlre- 

3  monitors. 

4  monitors. 

4  monitors. 

Better  than 

tighting 

3,000  gpm, 
3,435  gal  foam 
tank 

4,000  gpm, 
3,600  gal  fc«am 
tank 

2,600  gpni, 
10,500  gal 
foam  tank 

T.ATF-TARS 

Bcom’'Crane 

1 0  t  SWL  crane 

40 1  SWL  der¬ 
rick 

30  t  SWL  der¬ 
rick 

A-Frame  aft 

50 1  crane 
lot  crane  fwd 

Ground  Tackle 

3  anchors  asso¬ 
ciated  gear 

8  anchors. 
ass<:ciatedgear 
1.6  complete 
legs  of  beach 
gearj 

6  anchors, 
associated  gear 

capable  of  4- 
point  moor 

Repair  shcp 

Very  small 
workshop 

Large  machine 
shop 

Large  machine 
shcp 

Large  machine 
shop  module 

Table  3.  Equipage  of  the  four  elasses  displayed  in  Table  1 
(From:  Sperling  &  Keenan,  2006) 


Features 

TATF 

TARS 

lohn  Ross 

MSC  PMI 

Towing 

Towing  winch 

Towing 

2  friction 

Latest  design 

Arrangement 

(1  wire  rope 

machine  1.2 

winches,  each 

commercial 

drum  and  trac¬ 

wire  rope 

with  associated 

towi  ng 

tion  machine. 

drums  and 

spooling 

arrangement 

400  fathoms 

traction 

winch,  storing 

2.25  in.  wire) 

machine,  500 

1 ,000  fathoms 

automatic 

fathoms  2.25 

of  2.8  in  and 

towing 

machine 

in.  wire! 

2,2  in.  wire 

Propulsion 

2  ^tSD^  2 

4  HSO^",  2 

2  .NASD,  1 

MSD,  reduc¬ 

reduc  gears. 

reduc  gears. 

reduc  gear  CPP 

tion  gear  and 

twin  shafts. 

twin  shafts. 

fixed  nozzle. 

CPP  system 

CPP,  2  fixed 

CPP,  2  fixed 

twin  ru defers. 

nozzles,  twin 

nozzles,  twin 

800  bhp  bew 

rudders,  300 

rudders,  500 

truster 

bhp  bow 

bhp  bcw 

truster 

truster 

a.  MSD  =  medium  ?peed di«el, 

b.  HSD  =  high  speed  di«el 

Table  4.  Equipage  of  the  four  elasses  displayed  in  Table  2 
(From:  Sperling  &  Keenan,  2006). 
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E,  DECOMPRESSION 

All  types  of  ship,  weapon,  and  aireraft  salvage  work  require  diving  personnel  in 
suffieient  numbers  for  extensive  underwater  operations.  They  seareh  for  and  loeate 
underwater  objeets  and  obstaeles,  survey  underwater  damage,  attaeh  lifting  devices,  cut 
sunken  ship  hull  structures,  and  perform  many  other  underwater  tasks.  Such  work  often 
must  be  done  at  a  variety  of  depths,  necessitating  both  scuba  diving  and  hard-hat  diving 
skills.  Salvage  ships  are  often  the  platform  of  choice  for  deep  ocean  search  and  recovery 
(300  to  20,000  ft  of  sea  water)  with  SUPSALV  search  and  recovery  assets  (Sperling  & 
Keenan,  2006). 

Supporting  a  large  number  of  divers  for  a  long  period  of  time  necessitates  that  the 
salvage  ship  also  have  appropriate  multiple  diver  decompression  capability.  The  Navy 
uses  a  Standard  Navy  Double  Lock  system  that  permits  medical  personnel  to  lock  in  and 
lock  out  to  treat  divers  being  decompressed.  The  remainder  of  the  Double  Lock  system 
beyond  the  chamber  should  be  a  plug-in  from  the  current  Fly  Away  Diving  System 
(FADS)  technology.  In  recent  years,  hyperbaric  evacuation  (decompression  lifeboats) 
has  been  rigorously  enforced  by  the  civilian  ship  classification  societies,  and  should  be 
considered  in  any  future  diving  support  ship  used  by  the  Navy  (Sperling  &  Keenan, 
2006). 

The  modem  deep-sea  dive  teams,  such  as  MDSU  are  air-mobile,  refer  to  their 
teams  as  Air  Detachments.  To  facilitate  rapid  deployment  and  ease  of  use,  prepackaged 
surface-support  systems  were  developed  and  containerized.  These  modular  systems, 
displayed  in  Figure  13  are  referred  to  as  “Fly-Aways”  (Lonsdale,  2007). 
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Figure  13.  The  Saturation  Fly  Away  Dive  System  (SAT  FADS) 

(From;  Whaley,  2008) 


The  SAT  FADS  are  capable  of  conducting  combat  salvage  and  recovery 
operations,  from  crisis  response  to  emergent  casualties,  around  the  world’s  littorals  to  at 
least  600  ft.  They  are  capable  of  responding  rapidly  to  missions  that  support  national 
security  requirements  including  object  recovery  and  internal  wreck  penetration  or  to 
support  rescue  capabilities.  “To  meet  these  requirements  the  system  must  be;  air  &  road 
transportable,  fully  operational  to  a  minimum  depth  of  at  least  600  feet  salt  water,  operate 
from  a  vessel  or  craft  of  opportunity”  (Whaley,  2008). 

F.  DYNAMIC  POSITIONING 

Traditionally,  the  Navy  uses  a  four-point  mooring  system  to  position  the  salvage 
ship  when  operating  divers.  Dynamic  positioning  systems  are  classified  by  the  American 
Bureau  of  Shipping  by  the  extent  of  redundancy  built  into  the  system.  Class- 1  has  no 
redundancy,  and  is  not  used  with  divers.  Class-2  can  continue  to  hold  position  with  a 
single  fault,  excluding  loss  of  a  compartment.  That  is,  it  has  two  independent  computer 
systems  and  this  positioning  system  can  be  used  with  divers,  within  the  restrictions 
established  by  the  Supervisor  of  Salvage.  Class-3  has  the  most  redundancy  and  can  hold 
position  following  any  single  fault  including  loss  of  a  compartment  due  to  fire  or 
flooding,  having  at  least  two  independent  computer  systems  with  a  separate  backup 
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system.  The  DP-3  positioning  system  ean  also  be  used  with  divers.  A  DP-3  ship  that 
loses  an  engine  room  will  not  deviate  from  its  positioning  objective  (Sperling  &  Keenan, 
2006). 


G.  FIREFIGHTING 

Current  Navy  off-ship  firefighting  can  be  accomplished  by  both  classes,  though 
firefighting  capabilities  remain  insufficient.  The  ARS,  the  Navy’s  most  capable  fire¬ 
fighting  ship,  can  apply  foam  at  a  rate  of  1,250  gallons  per  minute  (gpm)  for  15  minutes. 
In  comparison,  Smit-Rangoon  pumped  foam  at  3,300  gpm  for  an  hour  and  a  half,  while 
assisting  USS  Stark  in  1987.  Using  the  data  from  the  fire  that  occurred  aboard 
USS  Stark,  the  Navy’s  best  firefighting  assets  did  not  carry  a  sufficient  quantity  of  foam 
and  did  not  have  sufficient  pumping  rates  to  extinguish  fires  on  small  ships  such  as  the 
one  on  the  Stark.  Additionally,  at  a  minimum,  such  a  ship  should  carry  210  short  tons  of 
Aqueous  Film-Forming  Foam  (AFFF)  at  3  percent  concentrate  and  be  able  to  deliver 
foam  at  a  rate  of  4,000  gpm  for  at  least  an  hour  (Sperling  &  Keenan,  2006). 

H.  BOLLARD  LIFT 

Often  it  is  necessary  in  wartime  to  open  or  clear  blocked  waterways  or  harbors  to 
improve  logistic  flows  to  engaged  forces  ashore.  Because  of  this  combat  requirement. 
Navy  salvage  ships  were  often  designed  with  a  static  lift  wherein,  by  ballasting  down  and 
then  clearing  the  ballast  tanks,  they  can  lift  large  objects  from  a  harbor  floor  and  move 
them  out  of  the  way.  For  heavy  lift  of  sunken  material,  the  ARS  can  exert  300  tons  of 
lifting  force  via  stern  and  bow  rollers  (SS500-AM-MMO-010,  2007).  The  ARS  is 
equipped  with  10-ton  capacity  crane  and  has  a  maximum  lift  of  100  tons  over  stem 
rollers.  The  aft  boom  on  the  ARS  forms  a  compensating  system  with  its  vang  and 
topping  tackle,  which  allows  for  simultaneous  control  of  slewing  and  topping  ensuring 
load  stability  up  to  40  tons.  The  forward  boom  on  the  ARS  also  has  this  capability  up  to 
7.5  tons  when  rigged  in  the  aft  position  (SS500-AM-MMO-010,  2007). 
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I. 


BOLLARD  PULL 


The  towing  force  exerted  at  zero  speed  and  full  power  is  called  bollard  pull.  This 
is  a  measure  of  the  strength  of  a  ship  to  tow  other  ships.  Typically,  bollard  pull  is 
measured  in  tons.  The  bollard  pull  of  existing  Navy  salvage  ships  was  compared  to 
commercial  salvage  ships,  and  were  found  to  have  much  less  bollard  pull  and  to  not 
handle  the  towing  of  larger  ships  in  a  seaway.  Figure  14,  taken  from  the  earlier  T-ATF 
study,  was  developed  using  the  Navy  Towing  Manual.  It  shows  the  force  needed  to  pull 
four  Navy  ships  of  different  sizes  at  various  speeds  in  sea  state  3.  The  towing  force 
increases  approximately  as  the  square  of  the  speed. 


Tov»  spe«d  (knots) 

Figure  14.  Force  needed  to  pull  Navy  ships  (From:  TOWMAN,  1998) 

As  Figure  14  shows,  the  current  towing  ship  (T-ATF),  when  rated  at  120  tons  bollard 
pull,  is  able  to  tow  a  surface  combatant  at  speeds  up  to  10  knots,  whereas  a  salvage  ship 
(ARS)  would  be  limited  to  about  7  knots.  Comparatively,  the  larger  commercial  towing 
ships  could  perform  the  same  task  in  about  half  the  time,  at  about  13  knots.  For  towing 
larger  ships,  the  tow  capability  of  the  current  salvage  ship  is  marginal  at  best.  The 
replacement  for  both  the  towing  ship  and  the  salvage  ship  should  have  improved  towing 
capabilities.  Figure  14  also  plots  the  towing  capabilities  of  some  typical  commercial 
rescue  ships:  Smit-Singapore  of  The  Netherlands,  John  Ross  of  South  Africa,  and  DeDa 
of  China  (Sperling  &  Keenan,  2006). 
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J.  CENTER  FOR  NAVAL  ANALYSIS  (CNA)  STUDY 

CNA  has  produced  three  salvage  ship-related  studies  over  the  past  few  years. 
Five  years  ago,  they  reported  a  series  of  alternatives  for  decision  makers,  making  the  ease 
for  various  levels  of  salvage  and  ocean-towing  ships  in  wartime.  That  work  included  a 
detailed  examination  of  anticipated  damage  to  combatants  in  battle  and  estimates  of 
damage  control  and  at-sea  salvage  efforts  necessary  to  save  the  damaged  ships  from 
falling  into  the  hands  of  a  determined  enemy.  Based  on  that  work,  the  Navy  chose  to 
keep  its  active  foree  of  four  Navy-manned  salvage  ships  and  five  CivMar-manned  oeean 
towing  ships.  The  study  also  suggested  that  forward  positioning  would  permit  sueh  a 
small  force  of  slow  ships  to  be  responsive  to  various  likely  wartime  seenarios, 
worldwide.  Since  1998,  NAVSEA  OOC  has  contracted  in  peacetime  123  oeean-towing, 
salvage,  and  search-and-recovery  operations  to  commercial  ship  operators.  This  is 
almost  19  events  per  year. 

During  the  period  1999  to  2005,  the  Navy  had  four  salvage  ships  and  four  to  five 
towing  ships  in  service,  supporting  both  fleets.  One  towing  ship,  T-ATF-167,  was 
inactivated  in  September  1999,  and  another  was  sent  to  the  inactive  ship  facility  in  2005. 
In  the  earlier  period,  the  civilian-manned  towing  ships  were  at  sea  significantly  more  than 
the  salvage  ships.  In  the  data  for  2005,  they  seem  to  be  spending  an  equal  amount  of 
their  time  at  sea.  However,  the  ARS  assigned  to  Hurricane  Katrina  harbor  clearanee  may 
have  skewed  the  data  for  2005.  Figure  15  displays  a  proportional  eomparison  of  the  time 
each  class  has  been  underway  (Sperling  &  Keenan,  2006). 
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Figure  15.  ARS  vs.  T-ATF  usage  (From;  Sperling  &  Keenan,  2006). 
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The  Navy  now  has  four  ARS  salvage  class  ships  and  the  remaining  four 
ocean-towing  ships  of  the  T-ATF-166  class  entered  service  between  the  end  of  May  1980 
and  the  end  of  July  1981.  They  will  collectively  reach  35  years  of  service  life  in  2015. 
The  Navy  has  a  draft  plan  to  replace  all  four  towing  ships  between  2014  and  2016.  The 
four  salvage  ships  of  the  ARS-50  class  were  commissioned  and  entered  service  between 
mid- August  1985  and  mid-November  1986.  They  will  reach  35  years  of  service  life  in 
2021.  The  shipbuilding  plan  does  not  extend  far  enough  to  specifically  identify  a  cost  for 
replacing  the  salvage  ships  when  they  are  no  longer  serviceable. 

K.  FUTURE  PLATFORM  REQUIREMENTS 

In  1989,  CNA  developed  a  set  of  tentative  operational  requirements  for  the  Ships 
Characteristics  Improvement  Board  of  the  Office  of  Chief  of  Naval  Operations  for  a  new 
and  future  class  of  salvage  and  towing  ship  (Light,  2007).  The  force-level  requirements 
have  been  derived  from  the  combatant  ship  force-sizing  scenarios  and,  from  them, 
calculated  likely  cases  of  possible  combatant  ship  casualties,  with  the  assumption  that 
ships  hit  are  savable.  Therefore,  they  offer  potential  at-sea  salvage  cases  to  which  the 
salvage  ships  and  ocean-towing  ships  can  be  applied.  The  work  investigated  the  current 
Navy  salvage  assets  (such  as  the  T-ATS-1,  T-ATF-166,  and  ARS-50  classes)  and  showed 
that  a  faster  salvage  ship,  capable  of  applying  more  foam  onto  a  ship  on  fire  for  longer 
periods,  would  be  desirable. 

With  all  salvage  and  towing  ships  manned  by  CivMars  and  now  available  for  up 
to  270  days  a  year,  four  ARSs  are  sufficient  to  meet  the  peacetime  employment 
prediction.  Unfortunately,  to  be  responsive  to  likely  wartime  needs,  the  ARSs  need  to  be 
forward  where  there  is  little  peacetime  towing  activity  and  very  little  high-visibility 
peacetime  salvage  work.  Consequently,  as  many  as  four  ocean-towing  assets  (T-ATFs) 
should  be  retained  to  permit  the  force  to  perform  both  the  peacetime  and  the  wartime 
jobs. 
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The  USFF  analysis  suggested  the  eombined  warfighting  and  peaeetime 
requirements  are  nine  vessels  to  aeeomplish  both  towing  and  salvage  tasks;  an  aeeeptable 
risk  would  be  eight.  CNA  analysis  suggests  seven  ships,  augmenting  with  eontraeted 
eommereial  tows  as  needed.  Currently,  the  warfighting  requirement  dominates  peaeetime 
demand  (Light,  2007). 

To  aeeommodate  a  ship-building  plan  for  eight  ships  of  a  single-hull  type,  the 
assumption  is  made  to  establish  a  timeline  to  begin  lead  ship  eonstruetion  in  FY16.  The 
notion  is  to  replaee  the  legaey  ships  (both  ARS  and  ATF)  near  their  end  of  serviee  life 
(ESL)  of  40  years.  Preconstruetion  aetivities  should  begin  in  FYIO;  starting  with 
establishing  an  IPT,  aequisition  strategy,  and  formalizing  ship  requirements  (Light, 
2007).  In  following  years,  a  notional  timeline  is  as  follows: 

FY12  Perform  eoneept  and  preliminary  design  and  program  doeumentation. 

FY13  Develop  notional  design,  eost  estimates,  and  eontraet  doeumentation. 

FY14  Award  eompetitive  Phase  I  design  eontraets  and  oversee  design  phase. 

FY15  Complete  design  phase;  execute  source  selection  for  Detail  Design  and 
Construction  phase. 

FY16  Award  contract  for  Phase  II  Detail  Design  and  Construction. 

L,  SUMMARY 

The  salvage  platforms  of  the  Navy  have  become  a  vital  part  of  a  wide  range  of 
military  operations,  as  highlighted  in  this  chapter.  The  life  cycle  of  the  current  towing 
and  salvage  ships  are  soon  coming  to  an  end,  with  a  need  for  a  future  possible  single-hull 
salvage  platform  within  the  next  10  years.  At  this  time,  an  SoS  architecture  has  not  yet 
been  developed  to  attain  the  proper  systems  requirements,  based  on  the  community’s 
needs.  The  architecture  elements  data  for  the  towing  and  salvage  community  has  not  yet 
been  entered  into  the  current  NAERG  metrics.  All  other  system  functions,  activities, 
elements,  and  nodes  that  have  not  yet  been  recorded,  have  been  entered  into  the  towing 
and  salvage  architecture  for  the  purpose  of  this  thesis. 

United  States  Navy  salvors  depend  on  the  systems  needed  to  successfully 
complete  their  missions,  maintain  equipment  functionality,  and  operate  in  extreme 

environments.  To  enable  timely  and  reliable  mission  completion,  individual  systems 
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must  work  efficiently  together  as  an  SoS.  Desired  requirements  have  been  proposed  by 
SEA  OOC  based  on  current  ship  capabilities,  and  require  a  capability-based  requirements 
generation  process,  based  on  the  current  and  future  mission  objectives.  This  proposed 
requirements-based  architecture  has  been  defined  as  being  a  single-hulled  ship  that  meets 
mission  needs  and  stakeholders’  concerns,  which  synthesizes  a  design  for  acquisition  of 
this  new  ship  class.  The  alternative  is  to  utilize  the  commercial  market,  analyzing  the 
capability-based  architecture  defined  in  this  thesis.  An  explanation  of  the  architecting 
process,  and  its  application  with  an  architecting  tool,  is  described  in  Chapter  III. 
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III.  MISSION  ANALYSIS 


Since  the  beginning  of  warfare,  sueeessful  military  leaders  have 
reeognized  the  importanee  of  knowing  the  enemy,  knowing  the  terrain, 
and  knowing  themselves  (Skolniek  &  Wilkins,  2000). 

A,  BACKGROUND 

The  eomplexity  assoeiated  with  oeean  salvage  operations,  particularly  deep  water 
operations,  makes  this  knowledge  of  enemy  terrain  and  themselves  even  more  crucial. 
The  DoD  must  ensure  that  the  towing  and  salvage  eommunity  is  developing  systems  to 
aeeomplish  their  assigned  missions  in  a  timely  manner  and  positioning  them  aecordingly. 
In  order  to  provide  the  salvage  platform  baseline  for  trade  studies  to  establish  a  CONOPS 
for  salvage  SoS  design,  the  DRM  coneept  will  be  used. 

A  DRM  defines  the  operational  aetivities  neeessary  for  mission  eompletion. 
“Also,  the  DRM  establishes  the  baseline  for  subsequent  systems  engineering  aetivities  - 
partieularly  generation  of  requirements,  refining  problem  definition,  development  of 
eoneepts,  and  analysis  of  alternatives,  and  testing  and  evaluation.  A  well  developed 
DRM  will  faeilitate  generation  of  requirements  and  subsequent  system  design”  (Skolniek 
&  Wilkins,  2000). 

“For  the  government  led  development  proeess,  the  DRM  feeds  the  development 
and  eertification  of  a  system  funetional  baseline  and  provides  support  through  the  entire 
life  of  the  program.  Thus  the  DRM  must  support  the  program  throughout  the  systems 
engineering  proeess”  (Skolniek  &  Wilkins,  2000).  To  ensure  that  the  final  iteration  of  the 
DRM  is  the  best  solution  for  eapabilities-driven  requirements  generation,  it  is  important 
to  receive  feedback  from  all  actors  associated  with  the  system  and  then  to  refine  the 
DRM  based  on  that  feedback. 

Composing  a  DRM  begins  with  understanding  the  operational  eoneept  of  the 
system  and  then  plaeing  that  system  into  a  simulated  environment  in  whieh  it  ean 
perform.  Onee  in  a  mission-exeeutable  environment,  the  eapabilities  or  operational 
aetivities  neeessary  to  eomplete  that  mission  will  beeome  apparent.  Designing  a 
referenee  mission  begins  with  understanding  the  environment  within  the  mission 
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analysis,  which  consists  of  defining  the  target  and  refining  the  mission  seenarios.  A 
seenario  ineludes  the  goal,  the  deployment  of  the  systems,  the  physical  environment  in 
whieh  the  mission  takes  plaee  or  is  exeeuted,  and  the  change  the  environment  will 
undergo  as  the  seenario  progresses. 

The  evolving  DoD  systems  aequisition  proeess  heightens  the  need  for  the 
operating  baseline  provided  by  the  DRM.  The  traditional  aequisition 
proeess,  i.e.,  one  in  whieh  a  government  team  develops  detailed  system 
speeifieations  that  are  then  provided  to  industry  to  guide  system 
development,  has  been  modified  to  involve  industry  earlier  in  the  proeess 
(Skolniek  &  Wilkins,  2000). 

For  effeetive  SE,  aeeurate  problem  solving  eannot  oeeur  without  proper  problem 
definition.  A  preeoneeived  problem  solution  or  requirements-first  SE  results  in  biased 
design.  The  generation  of  a  DRM  for  problem  definition  will  lead  to  an  aeeurate  problem 
solution  to  support  the  range  of  stakeholders’  needs. 

B,  DESIGN  REFERENCE  MISSION  (DRM):  PROJECTED  OPERATIONAL 
ENVIRONMENT  (POE) 

The  POE  is  the  environment  in  whieh  the  ship  is  expeeted  to  operate.  It  provides 
the  neeessary  details  to  deseribe  the  mission  areas,  environment,  and  types  of  loeations  to 
determine  the  operational  eapabilities  for  whieh  the  ship  elass  will  be  designed.  The  POE 
provides  information  for  establishing  tasks  that  produee  a  measurable  workload  used  to 
eompute  manpower  requirements.  The  T-ARS(X)  will  perform  the  eapabilities  of  both 
towing  and  salvage  platforms,  thus  it  will  need  the  same  operational  requirements 
listed  below: 

TATE- 166  POE  (OPNAV  Instruetion  3501.177,  1988) 

•  At  sea  in  wartime. 

•  To  perform  towing  at  sea  operations. 

•  To  perform  rescue  towing  and  limited  salvage  at  sea  serviee. 

•  To  perform  debeaching  operations. 

•  To  extinguish  fires  on  ships  in  distress. 

•  Aet  as  support  ship  for  the  deployment  and  reeovery  of  portable  oil  spill 
reeovery  equipment  and  portable,  self-sustaining,  deep  diving  equipment. 
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•  Capable  of  performing  all  maintenanee  for  which  ship’s  company  is 
assigned  responsibility. 

ARS-50  POE  (OPNAV  Instruction  3501.136b,  2007) 

•  Operate  at  sea  in  wartime  in  cooperation  with  joint/allied  forces. 

•  Operate  in  littoral  environment. 

•  Capable  of  performing  all  defensive  functions  simultaneously,  while 

maintaining  readiness  condition  I. 

•  Capable  of  performing  other  functions  that  are  not  required  to  be 
accomplished  simultaneously. 

•  Capable  of  maintaining  readiness  condition  III  at  sea. 

•  Capable  of  performing  salvage,  diving,  and  emergency  towing  at 
sea  operations. 

•  Capable  of  performing  all  maintenance  for  which  ship’s  company  is 
assigned  responsibility. 

•  Capable  of  providing  fire-fighting  assistance  to  other  ships. 

1,  Geography 

Figure  16  displays  the  setting  for  this  DRM,  the  Gulf  of  Mexico,  and 
New  Orleans,  Louisiana. 


Figure  16.  Map  of  Gulf  of  Mexico  and  New  Orleans,  Lousiana 
(From;  Google  maps,  2008) 
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2. 


Maritime  Conditions 


Sea  State 

Gulf  of  Mexico  <2 
Water  Temperature  Isothermal 

Day  83  F 

Night  81  F 

Bathymetry 

Depth  4m  -  12m 

Bottom  Types  Sand,  Mud 

Currents 

Gulf  of  Mexico  near  Mississippi  river  outlet  3  kts 

3,  Climatic 

The  climate  is  described  as  hot,  humid,  and  rainy.  Thunderstorms  occur  daily 
from  May  to  October.  Tornados  and  waterspouts  occur  throughout  the  summer  months. 
Hurricanes  occur  from  June  through  September. 

4,  Meteorological  Date:  04  July  2008 
Temperature 

Average  Maximum  88-91  F 

Average  Minimum  69-71  F 

Extremes  60-98  F 

Winds 

Mean  Surface  12  mph 

December  -  April  from  southeast 

June  -  October  from  northwest 

Relative  Humidity 

Mean  89% 

Diurnal  Range  65%-98% 

Precipitation 

Average  Annual  Rainfall  61.88  inches 
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C.  DESIGN  REFERENCE  MISSION  (DRM):  POTENTIAL  SALVAGE 
TARGETS 

FLOODED/SUNKEN/DAMAGED/LOST  VESSEL: 

1 .  Eishing  vessels  in  transit  lane  requiring  repair  and  tow. 

2.  Damaged  fuel-oil  system,  pollution  response. 

3.  Lost  craft  in  need  of  medical  assistance. 

D.  DESIGN  REFERENCE  MISSION  (DRM):  CHARACTERISTICS  OF 
SUNKEN  VESSEL  IN  TRANSIT  LANE 

The  specific  target  is  defined  by  the  problem  as  a  sunken  fishing  vessel  impeding 
the  transit  lane  at  the  mouth  of  the  Mississippi  River  outlet.  This  section  will  describe  the 
fishing  vessel,  displayed  in  Figure  17,  in  general  and  those  specifically  registered  to 
operate  near  the  Mississippi  Sound. 


Figure  17.  Large  fishing  vessel  aground  to  simulate  mission  objective 

(From:  Wikipedia,  2008) 


1,  Size 

There  are  many  fishing  vessels  of  various  sizes  that  pass  through  the  mouth  of  the 
Mississippi  River.  For  this  model,  a  large  vessel,  approximately  130  ft  long  and 
150  tons,  will  be  used. 


49 


2. 


Position 


The  position  of  the  sunken  vessel  will  be  at  the  mouth  of  the  Mississippi  River 
near  Vinice,  Louisiana,  as  indicated  in  Figure  18. 


Chandeleur 

;^Sbur>d< 


Breton 
<  SbuhTd 


^Gol^n 

Meedow 


Figure  18.  Location  of  fishing  vessel  and  mission  environment 
(From;  Google  maps,  2008) 


3,  Depth 

The  depth  at  the  target  location  is  12m  at  high  tide  at  the  stern  of  the  vessel  and 
4m  at  the  bow  of  the  vessel. 


4,  Damage 

The  vessel  has  a  2m  diameter  hole  in  the  starboard  quarter.  Once  patched,  the 
structure  will  be  water  tight.  The  propulsion  system  has  been  flooded  and  is  inoperable. 
Once  floated,  the  vessel  will  be  dead  in  the  water  and  not  under  command. 
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E,  DESIGN  REFERENCE  MISSION  (DRM):  OPERATIONAL  SITUATIONS 

(OPSIT) 

1.  Discussion 

In  order  to  develop  a  eomprehensive  and  efficient  system,  the  system 
developer/engineer  must  go  through  the  planning  process  to  determine  “how”  the  mission 
will  be  accomplished.  The  product  of  this  mission  analysis  is  a  plan  that  details  tasks  to 
be  assigned  to  the  SoS  in  order  to  complete  the  mission.  A  mission  consists  of  multiple 
operations,  and  its  execution  typically  involves  multiple  systems  simultaneously 
conducting  a  variety  of  assigned  tasks.  These  tasks  are  integrated  and  synchronized  in 
order  to  anticipate  the  operational  requirements  necessary  to  achieve  the  mission. 

OPSITs  can  depict  task  lists  in  required  for  the  necessary  operational  activities. 
Operations  templates  provide  a  graphical  description  of  the  activities  and  tasks  involved 
in  mission  planning,  along  with  their  interrelationships.  There  are  various  characteristics 
of  activities,  ranging  from  a  one-time  occurrence  to  a  continuous  event.  An  example  of 
an  activity  that  may  occur  only  once  over  the  defined  mission  time  period,  is  the  platform 
deployment  to  the  mission  theater.  Other  tasks  may  be  continuous,  like  positioning  the 
salvage  vessel  in  deep  water.  Each  of  these  types  of  tasks  can  be  represented  and 
distinguished  within  a  design  reference  mission.  OPSITs  can  depict  tasks  required  to 
perform  the  mission  commander’s  CONOPS.  The  commander  determines  the  tasks  that 
are  essential  to  mission  success  and  identifies  these  as  Mission  Essential  Tasks. 

“OPSITs  templates  are  discrete  multi-engagement  event  diagrams  with  specified 
operational  characteristics.  The  use  of  discrete  OPSITs  provides  a  set  of  fixed  ‘test 
points’  that  collectively  yield  a  representative  sampling  of  the  problem  space”  (Skolnick 
&  Wilkins,  2000).  These  test  points  are  displayed  in  Eigure  19,  with  an  example  of  a 
DRM.  “Users  are  encouraged  to  conduct  a  parametric  exploration  of  the  problem  space 
to  aid  concept  definition,  with  the  understanding  that  OPSITs  are  specifically  developed 
to  stress  selected  system  design  attributes  and  support  functional  and  performance  trade¬ 
off  analysis”  (Skolnick  &  Wilkins,  2000).  Each  OPSIT  should  feature  one  or  more 
stressing  operational  characteristics  that  will  support  a  high-stress  condition  to  a 
functional  trade  space. 
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Figure  19.  DRM  OPSIT  construct  example  (From;  Skolnick  &  Wilkins,  2000). 


OPSITs  can  be  thought  of  as  specific  instances  of  a  DRM  where  the  variables  can 
change,  creating  unique  OPSITs  for  that  mission  time.  OPSITS  can  be  compared  to  DoD 
testing  and  evaluation  (T&E)  in  that  the  system  is  stressed  within  a  real-time  scenario, 
verifying  that  the  system’s  capabilities  or  operational  activities  are  sufficient  to  perform 
the  mission  effectively.  Flowever,  OPSITs  differ  from  T&E  in  that  they  can  be  as  simple 
as  formalized  Table  Top  Exercise.  The  information  and  feedback  from  Subject  Matter 
Experts  (SMEs)  is  imperative  to  quality  OPSIT  development.  OPSITs  should  be 
validated  by  the  SMEs,  creating  a  balance  between  the  average  and  extreme  situations 
(Skolnick  &  Wilkins,  2000). 


2,  OPSIT  Generation 

Eor  every  operational  activity  assigned  to  a  mission,  a  set  of  operational  tasks  are 
defined  to  develop  a  CONOPS.  This  process  is  designed  to  identify  the  existing  military 
capabilities  required  to  execute  a  mission.  In  addition,  assumptions  are  made  about  the 
environment,  logistics,  deployment,  and  time  required  to  achieve  the  mission. 

Assumptions  are  realistic  variables  meant  to  provide  validity  to  the  scenario, 
while  keeping  it  manageable.  In  choosing  assumptions,  displayed  in  Table  5,  the 


52 


developer  must  determine  what  type  of  solution  should  eome  from  the  OPSIT.  In  this 
thesis,  all  events  are  assumed  to  oeeur  during  the  day,  but  subsequent  studies  eould 


examine  nighttime  seenarios. 


ASSUMPTIONS 

Date/Time 

04  July  2008/1200 

Ship  Type 

Fishing  Vessel 

Length 

40m 

Weight 

150  tons 

Damage 

2m  diameter  hole  in  starboard  quarter 

Pollution 

Oil  sheen 

Water  Depth 

<12m 

Visibility 

<lm 

Sea  State 

<2 

Bottom  Type 

Mud,  sand 

Structural  Integrity 

Intact 

Table  5.  DRM  assumptions 

For  this  work,  the  four  main  variables  that  will  ehange  will  be  Visibility,  Pollution 
Level,  Sea  State,  and  Damage.  Table  6  displays  the  OPSIT  variables  that  will  change 
with  time  and  environmental  effects.  The  target  characteristics  and  location  can  differ 
from  scenario  to  scenario;  however,  this  mission  will  stress  the  most  capabilities  and 


timing  requirements  that  a  possible  future  salvage  platform  may  encounter. 


Characteristic 

Stress  Level 

Value 

Probability 

Sea  State 

L 

1 

H 

M 

2 

M 

H 

3 

L 

Visibility 

L 

>2m 

M 

M 

>lm,  <2m 

H 

H 

<lm 

M 

Pollution  Level 

L 

No  Pollution 

L 

M 

Minimal  Pollution 

H 

H 

Major  Pollution 

M 

Damage 

L 

Single,  Repairable 

M 

M 

Multiple,  Repairable 

H 

H 

Multiple,  Unrepairable 

L 

Table  6.  OPSIT  variables  with  respective  stress  levels 
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Table  7  represents  the  extremes  for  mission  preparedness  showing  the  low-, 
average-,  and  high-stress  OPSIT  scenarios,  following  Skolnick’s  advice  that  OPSITs 
should  feature  one  or  more  stressing  operational  characteristic. 


Possible  OPSITs 

Sea  State 

Visibility 

Pollution 

Damage 

Eow-stress  OPSIT 

E 

E 

E 

L 

Average-stress  OPSIT 

M 

M 

M 

M 

High-stress  OPSIT 

H 

H 

H 

H 

Table  7.  Low-,  average-,  and  high-stress  OPSIT  scenarios 


3,  Mission  Success  Requirements 

The  OPSIT  will  identify  the  individual  activities  that  need  to  be  accomplished  in 
order  to  define  the  success  of  the  mission.  The  requirements  identified  for  the  success  of 
this  DRM  will  be  measured  in  four  categories: 

•  Removing  oily  waste. 

•  Lifting  the  vessel  from  the  bottom. 

•  Repairing  the  vessel  to  stability. 

•  Towing  the  vessel  away  from  the  mouth  of  the  river. 

The  mission  is  divided  into  these  categories  based  on  the  specific  functions  that 
each  individual  operational  activity  is  required  to  perform.  Each  category  must  be 
completed  in  order  to  identify  the  mission  as  being  successful. 

F.  MISSION  DEFINITION 

In  order  to  complete  the  mission  success  levels,  all  T-ARS(X)  salvage,  towing, 
heavy  lift,  diving,  and  pollution  response  capabilities  or  operational  activities  will  be 
utilized.  Each  mission  included  within  a  DRM  scenario  can  be  decomposed  into  the 
individual  operational  activities  necessary  to  complete  the  tasks  that  the  DRM  scenario 
requires.  The  DRM  is  decomposed  into  the  following  operational  activities: 

•  Towing. 

•  Salvage  (including  Heavy  Eift). 

•  Diving. 

•  Pollution  Response. 
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Once  all  operational  activities  or  eapabilities  have  been  identified,  the 
eomponents  required  to  achieve  the  funetions  necessary  to  complete  the  mission  will  be 
identified  and  documented. 
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IV.  ARCHITECTING  PROCESS 


A.  INTRODUCTION 

It  is  possible  to  do  either  an  SE  proeess  without  produeing  a  systems  architeeture, 
or  creating  an  architecture  without  subjecting  it  directly  to  an  SE  process.  However,  the 
quality  of  the  outcome  from  the  two  processes  done  independently  will  be  substantially 
lower  than  if  the  two  processes  are  done  in  conjunction.  “There  is  a  great  need  to 
describe  a  process  to  ensure  that  the  architecture,  the  arrangement  of  elements  and  their 
relationships,  is  well-defined  and  addresses  the  needs  of  the  stakeholders”(DoDAE, 
2004). 

The  purpose  of  this  chapter  is  to  describe  the  steps  taken  to  develop  an  SoS 
architecture,  from  the  mission  design  to  the  system  specification,  with  the  aid  of  an 
architecting  tool.  The  development  of  an  architecture  using  CORE  is  defined  for  the 
future  salvage  platform  SoS  and  adequately  identifies  the  capability-based  requirements 
in  terms  of  the  operational  mission  objectives.  This  chapter  also  illustrates  how  a  U.S. 
Navy  Diving  and  Salvage  system  could  be  architected  in  the  context  of  an  SoS  from  an 
identified  set  of  stakeholder  needs. 

The  MBSE  integrated  methodology  is  used  to  select  the  most  efficient  SoS 
architecture.  The  identification  of  the  salvage  platform  SoS  begins  with  the  mission 
objectives  from  the  CONORS  of  the  salvage  force,  to  developing  a  DRM,  and  leading  to 
an  appropriate  architecture  supported  by  modeling  and  simulation.  The  framework  used 
in  the  development  of  the  SoS  architecture  is  modeled  in  CORE,  and  will  be  used  as  a 
foundation  for  future  capability-based  architectural  modeling  for  the  future  salvage 
platform  force  structure  (Huynh  &  Osmondson,  2007). 

Key  outcomes  described  in  this  chapter  are  an  architecting  and  architecture 
generation  process  (with  focus  on  stakeholder  needs),  ideally  suited  to  salvage  systems 
complemented  by  an  SE  process — from  engineering  requirements  definition  to  physical 
architecture  integration — for  fusing  the  diverse  assets  involved  in  this  complex  system. 
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B,  CORE  5  ARCHITECTURE 

A  major  challenge  in  the  arehiteeting  proeess  is  developing  an  arehiteeture  so  that 
the  system  elements  are  eomplete  and  eonsistent  with  one  another.  An  arehiteeting  tool 
is  a  great  asset  that  is  used  to  verify  that  the  data  is  consistent  and  that  all  element 
eonnections  remain  with  their  assoeiated  eounterparts.  The  amount  of  data,  when 
eomplying  with  arehiteeture  standards  sueh  as  the  DoDAF,  is  too  large  to  manipulate 
manually.  The  CADM  ean  aid  in  this  task. 

CORE  is  a  unified  model  that  integrates  the  arehiteetural  frameworks  with  the 
SoS  development  proeess  and  the  element  relationship  representation  of  the  SoS  model. 
“The  CORE  produet  suite  is  a  fully  integrated,  flexible  approaeh  to  a  eollaborative 
produet  design  speeifieally  developed  by  systems  engineers  for  systems  engineers” 
(CORE  5  ADG,  2007).  CORE  delivers  a  mutual  design-centrie  approaeh  to  product 
development.  “CORE  provides  comprehensive  traeeability  from  need  definition  through 
requirements  and  analysis  to  arehiteeture  and  test.  Built  upon  a  proven  approaeh  and  a 
central  integrated  design  repository,  CORE  includes  a  eomprehensive  behavior  modeling 
notation”  (CORE  5  ADG,  2007). 

Operational  models  are  developed  using  MBSE  prineiples.  The  design  aetivities 
integrate  the  operational  model  and  the  systems  model,  and  eonsist  of  requirements 
analysis,  funetional  analysis,  physieal  arehiteeture  synthesis,  and  verifieation  and 
validation  (CORE  ADG,  2007).  All  steps  of  the  SE  proeess,  as  deseribed  in  Chapter  I, 
ean  be  eompleted  using  this  CORE  model-based  SE  arehiteeture. 

“CORE  foeuses  on  an  arehiteeture  synthesis  centrie  approaeh  rather  than  a  view 
or  document  eentrie  approach.  This  provides  traeeability  from  capability  through 
requirements  and  analysis  to  testing.  The  CORE  software  suite  was  designed  by  systems 
engineers  to  satisfy  diverse  eivilian  and  military  eustomer  (or  stakeholder)  needs” 
(Giammareo,  2007).  An  overview  of  the  MBSE  proeess  is  displayed  in  Figure  20,  whieh 
shows  the  stages  of  the  arehiteetural  development  proeess. 
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utilizing  a  layered  approach  to  progressively  clarify  and  elaborate  all  four  domains 
concurrently  ensures  consistency  and  compieteness. 


Figure  20.  CORE  Approach  Relationships  from  the  CORE  Architecture  Definition 
Guide  [DoDAF  version  1.5],  (From;  Vitech,  2007). 

CORE  is  built  around  a  central  integrated  design  repository.  It  includes  a 
comprehensive  behavior  modeling  notation  to  understand  the  dynamics  of 
a  design.  CORE  is  a  MBSE  tool  designed  to  integrate  architectural  and 
engineering  activities  while  developing  operational  and  system  models. 
Documentation,  such  as  the  DODAE  views,  are  derived  from  the  basis 
architecture  produced  (CORE  SE  Guided  Tour  Vitech  Corporation, 

August  2007). 

As  displayed  in  Eigure  20,  the  architecture  elements  from  the  DoDAF  version  1.5 
schema  are  integrated  into  a  database  of  element  classes  within  CORE  to  enable  the 
systems  engineer  to  define  the  element  relationships  and  display  the  system  hierarchies. 

The  architecture  is  divided  into  two  behavioral  domains:  operational  architecture 
and  system  architecture.  Each  domain  is  described  in  detail  below.  “The  Operational 
Architecture  Domain  captures  originating  concepts,  capabilities,  and  supporting 
operational  analysis  to  exploit,  whereas  the  System  Architecture  Domain  expresses  the 
requirements,  functions,  and  components  comprising  the  physical  design”  (CORE 
Architecture  Definition  Guide  [DoDAE  version  1.5],  Vitech  Corporation,  August  2007). 
Displayed  in  Eigure  21,  the  CORE  architecting  schema  separates  the  systems  and 
operational  domains  with  relationship  lines  connecting  the  individual  elements. 
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Figure  21.  CORE  DoDAF  Schema  (From;  Vitech,  2007) 

The  CORE  architectural  elements  that  will  be  focused  on  in  this  thesis  are  the 
Architecture,  Operational  Nodes,  Operational  Activities,  Missions,  Eunctions,  and 
Components.  Erom  these  elements,  the  necessary  DoDAE  architectural  views  and  system 
specification  document  can  be  formulated.  This  chapter  will  describe  in  detail  the 
individual  elements,  as  well  as  how  they  relate. 

C.  ARCHITECTURES 

“Architectures  exist  for  the  purpose  of  achieving  a  well-defined  system  in  both 
the  operational  and  system  domains,  for  a  specific  time  frame.  The  Architecture  class  is 
used  to  identify  an  architecture  and  its  time  frame”  (CORE  ADG,  2007).  Nodes  in  the 
systems  architecture  are  defined  as  components,  while  nodes  in  the  operational 
architecture  are  defined  as  operational  nodes.  Eor  the  towing  and  salvage  platform 
model,  the  architecture  was  created  as  “Towing  and  Salvage,”  with  the  operational  and 
systems  architecture  elements  completed  and  described  in  Eigure  22. 
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Figure  22.  Architecture  element  decomposition  (From:  Vitech,  2007) 

1,  Operational  Architecture 

Given  the  need  to  comply  with  the  framework  of  the  operational  requirements 
document,  the  systems  engineer  must  define  the  operational  behavior  in  order  to 
accomplish  the  mission.  The  operational  architecture  organizes  the  architectural 
elements,  which  compose  the  operational  behavior  of  the  system.  The  operational 
architecture  is  made  up  of  the  operational  nodes,  operational  activities,  operational  tasks, 
and  missions.  Creating  an  operational  architecture  begins  by  first  defining  the  mission, 
and  then  by  identifying  the  operational  activities  needed  to  accomplish  the  mission.  Once 
all  of  the  operational  activities  have  been  identified,  the  responsible  operational  nodes 
can  then  be  defined. 


2,  Operational  Nodes 


“Within  the  Operational  architecture  domain,  the  operational  node  is  part  of  the 
operational  context  which  also  includes  the  elements  that  represent  the  external  aspects  of 
the  operational  domain”  (CORE  ADG,  2007).  An  operational  node  is  a  representation  of 
an  actor  role  within  an  organization  that  produces  or  consumes  information.  The 
operational  nodes  for  the  future  towing  and  salvage  platform  are  all  of  the 
actors/organizations  that  interact  with  and  make  decisions  for  the  system.  They  include: 

•  SEA  OOC  (SUPSALV)  including  all  departments. 

•  MDSUs  One  and  Two. 


ESSM. 

MSFSC. 
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The  operational  nodes  ean  be  decomposed  and  displayed  in  CORE  as  a  system 
diagram,  as  shown  in  Figure  23.  Further  breakdown  of  the  operational  nodes  would 
characterize  operational  activities. 


Figure  23.  SEA  OOC  Operational  Node  decomposition 

3,  Operational  Activities 

In  conjunction  with  operational  architecture  synthesis,  for  each  layer  of 
operational  nodes,  operational  activities  are  decomposed  until  they  can  be 
uniquely  assigned  to  the  next  level  of  operational  node  using  the 
performed  by  relationship.  This  not  only  establishes  the  organization  or 
role  that  performs  the  activity,  it  allows  the  systems  engineer  to  assess  the 
impact  of  operational  node  failures  on  both  mission  and  operational 
activities  (CORE  ADG,  2007). 

Operational  activities  also  called  operational  scenarios,  consist  of  a  sequence  of 
capabilities  needed  to  respond  to  an  external  stimulus.  Each  operational  activity  is 
performed  by  an  element  within  the  operational  node  class  displayed  in  Figure  24. 
Finalized  capabilities  (operational  activities),  are  incorporated  to  become  the  integrated 
model  for  the  architecture. 


Figure  24.  Operational  Architecture  Diagram  with  relations  (From:  Vitech,  2007) 
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The  operational  aetivities  are  linked  to  the  systems  architecture  domain  through 
the  function  element,  and  are  traced  from  operational  nodes  and  achieve  operational  tasks 
and  missions,  as  displayed  in  Figure  25.  “Operational  activity  traceability  from  an 
appropriate  mission  element  is  established  using  the  ‘achieves’  relationship.  Establishing 
this  relationship  enables  one  to  easily  assess  what  capabilities  are  impacted  by  a  mission 
change  and  what  missions  are  impacted  by  a  capability  change  or  failure” 
(CORE  ADG,  2007). 


Eigure  25.  CORE  systems  view  of  the  operational  activity  “Towing” 
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4,  Required  Operational  Capabilities  (ROC) 

Required  Operational  Capabilities  (ROC),  as  eonstituted  by  mission  eommanders, 
detail  the  eapabilities  required  of  ships  in  various  operational  situations  outlined  in  the 
POE.  The  level  of  detail  is  deeomposed  to  outline  speeifie  mission  areas  and 
eomponent/operator  responsibilities.  The  ROC  provides  the  neeessary  details  of 
operational  eapabilities  for  whieh  the  ship  elass  was  designed,  based  on  expeeted 
missions.  It  will  establish  tasking  that  produees  a  measurable  workload  used  to  eompute 
manpower  requirements. 

TATE- 166  ROC  (High-level)  (OPNAV  Instruetion  3501.177,  1988) 

•  Antiair  warfare. 

•  Antisurfaee  warfare. 

•  Command,  Control  and  Communieations. 

•  Eleet  support  operations. 

•  Intelligenee. 

•  Mobility. 

•  Noneombat  operations. 

ARS-50  ROC  (High-level)  (OPNAV  Instruetion  3501.136b,  2007) 

•  Antiair  warfare. 

•  Antisurfaee  warfare. 

•  Command,  Control,  and  Communieations. 

•  Command  and  Control  Warfare. 

•  Eleet  support  operations. 

•  Intelligenee. 

•  Mine  warfare. 

•  Mobility. 

•  Missions  of  state. 

•  Noneombat  operations. 

The  ROC  is  further  deeomposed  into  operational  tasks  needed  to  fulfill  the 

operational  aetivity.  Eor  example,  the  operational  aetivity  “Mobility”  is  eomposed  of 

lower-level  aetivities  sueh  as  “move  through  the  water”  and  “eonduet  sustained 
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operations  underway.”  Eaeh  of  these  aetivities  ean  be  further  deeomposed  into  individual 
tasks  neeessary  to  achieve  the  activity  “move  through  the  water.” 

5.  Operational  Task 

The  operational  task  element  decomposes  a  list  of  mission-derived  tasks  with 
associated  conditions  and  standards  that  a  system  architect  may  select  to  accomplish  a 
simulated  mission.  The  Universal  Naval  Task  List  (UNTL)  is  a  combination  of  the  Navy 
Tactical  Task  List  (NTTL)  and  the  Marine  Corps  Task  List  (MCTL),  and  was  utilized  to 
identify  the  universal  tasks  that  the  towing  and  salvage  platform  must  perform. 

The  UNTL  contains  a  comprehensive  hierarchical  listing  of  the  tasks  that 
can  be  performed  by  a  naval  force,  describes  the  variables  in  the 
environment  that  can  affect  the  performance  of  a  given  task,  and  provides 
measures  of  performance  that  can  be  applied  by  a  commander  to  set  a 
standard  of  expected  performance  (UNTL,  2006). 

Along  with  the  UNTL,  there  are  task  lists  derived  from  a  hierarchy  of  DoD  tasks 
contained  within  the  Universal  Joint  Task  List  UJTL  displayed  in  Ligure  26.  Depending 
on  the  mission  level  being  developed,  a  certain  standard  of  tasks  are  required  to  fulfill 
that  mission-level  requirement.  If  the  mission  involves  joint  service  cooperation,  the 
tasks  would  be  derived  from  the  UJTL  at  a  higher-level  mission  perspective. 

Task  List  Hierarchy  N 


Ligure  26.  Task  List  Hierarchy 
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The  following  task  list  definitions  were  taken  from  the  OPNAV  Instruction 
3500.38B/MCO  3500.26AAJSCG  COMDT  Instruction  M3500.IB  CH-I: 

•  The  UJTL  (CJCSM  3500.04)  is  a  comprehensive  hierarchical  listing  of  the 
tasks  that  can  be  performed  by  a  joint  military  force.  It  serves  as  a 
common  language  and  reference  system  for  joint  force  commanders, 
combat  developers,  and  trainers.  The  UJTL  also  provides  a  basis  for 
describing  joint  requirements,  capabilities,  and  combat  activities. 

•  The  UNTL  (OPNAVINST  3500.38/)  is  a  comprehensive  hierarchical 
listing  of  Navy,  Marine  Corps,  and  Coast  Guard  tasks,  at  all  levels  of  war 
(the  UJTL  plus  the  Naval  Tactical  Task  List).  It  includes  all  those  tasks 
the  United  States  Navy,  Marine  Corps,  and  Coast  Guard  might  be  required 
to  perform  as  part  of  their  military  missions. 

•  A  Joint  Mission  Essential  Task  (JMET)  is  an  activity  selected  by  a  joint 
force  commander  deemed  critical  to  mission  accomplishment.  The  UJTE 
(version  4.0)  defines  essential  as  “absolutely  necessary;  indispensable; 
critical.”  The  Joint  Mission  Essential  Task  Eist  (JMETL)  is  the  joint  force 
commander’s  list  of  joint  tasks  considered  essential  for  accomplishment  of 
operational  plans  predicated  on  the  missions  assigned  and  forces 
apportioned  by  the  JSCP,  U.S.  alliance  or  treaty,  or  by  regional  initiatives. 

•  Naval  Mission  Essential  Tasks  (NMET)  are  those  tasks  considered 
essential  to  accomplish  and  support  missions  assigned  by  a  naval  or  joint 
force  commander.  NMETs  are  chosen  from  the  tasks  contained  in 
the  UNTE. 

In  order  to  complete  the  mission  requirements,  the  type  of  operation  must  be 
considered.  Each  mission  will  require  a  unique  set  of  capabilities  or  operational  activities 
due  to  the  variation  of  the  mission  environment.  Task  lists  are  uniquely  defined,  based 
on  a  higher-lever  mission  analysis  of  the  variation  in  operational  objectives.  Although 
many  of  the  tasks  within  the  different  lists  are  similar,  task  requirements  will  vary  based 
on  the  type  of  operation.  The  different  task  lists  are  hierarchically  displayed  in  Eigure  27. 
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Operational  elements  relationship 


V _ J 

Figure  27.  Mission-Op  Task-Op  Activity  Diagram 

As  stated  above,  the  task  list  identifies  “what”  is  to  be  performed  in  terms  of  the 
system  being  designed.  The  following  towing  and  salvage  tasks  were  derived  from  the 
UNTL  for  the  purpose  of  developing  a  CORE  architectural  model; 

•  Provide  Damage  Control. 

•  Conduct  Small  Boat  Operations. 

•  Sail  Ship  from  Port,  Anchorage,  or  Moorage. 

•  Return  Ship  from  Port,  Anchorage,  or  Moorage 

•  Employ  Remote  Vehicles. 

•  Conduct  Navigation. 

•  Conduct  Ship-to-Shore  or  Ship-to-Objective  Maneuver. 

•  Conduct  Sustained  Operations  Ashore. 

•  Conduct  Security. 

•  Conduct  Passage  of  Lines. 

•  Transport  Personnel. 

•  Transport  Cargo. 
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•  Provide  Support  Services. 

•  Employ  Communication  Security. 

•  Coordinate  Damage  Control  Operations. 

•  Conduct  Personnel  Recovery. 

•  Perform  Search  and  Rescue. 

•  Provide  Disaster  Relief. 

•  Provide  Emergency  Assistance. 

•  Provide  for  Operational  Safety  of  Personnel  and  Equipment. 

•  Conduct  Towing  Operations. 

•  Conduct  Salvage  Operations. 

•  Retract  Beached  Vessels. 

•  Conduct  Off-Ship  Eirefighting. 

•  Conduct  Heavy  Eift  Operations. 

•  Conduct  Diving  Operations. 

•  Conduct  Mooring. 

•  Conduct  Underway  Replenishment. 

These  tasks  were  derived  to  satisfy  the  capabilities  needed  in  order  to  perform  the 
higher-level  tasks  included  in  a  simulated  ROC/POE  developed  within  the  DRM.  These 
tasks  were  used  to  identify  the  required  operational  activities  necessary  to  complete  the 
proposed  DRM  and  further  recognize  the  operational  nodes  responsible  to  meet 
mission  needs. 


6,  Missions 

“Missions  are  hierarchically  organized  textual  descriptions  that  define  the  very 
existence  of  the  enterprise,  and  that  are  the  ultimate  goals  and  objectives  that  measure 
enterprise  accomplishment  from  within  different  business  functions  and  organizations” 
(Gorman,  2007).  The  first  step  in  the  architecting  procedure  is  defining  the  problem(s)  it 
will  be  built  to  solve,  and  ensuring  the  development  and  refinement  of  the  correct  data 
necessary  to  address  the  problem.  The  problem  definition  step  in  developing  a  system 
architecture  achieves  a  reference  mission,  to  which  the  operational  activities  of  the 
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system  will  need  to  be  demonstrated  within  a  mission  simulation.  In  CORE,  the  element 
relationship  for  the  decomposition  of  the  mission  element  was  derived  and  displayed  in 
Figure  28. 


Figure  28.  CORE  view  of  the  DRM  decomposition 

The  basis  for  all  of  the  required  elements  within  the  architecting  model  will  be 
developed  from  a  refined  DRM.  The  capabilities  from  the  DRM  will  drive  the  functions 
needed  to  implement  the  capabilities,  followed  by  the  system  components  needed  to 
perform  the  functions.  Once  these  elements  have  been  identified,  the  architecting  data 
model,  CORE,  will  be  utilized.  According  to  Figure  28,  the  mission  is  directly  achieved 
by  the  architecture. 

7,  Systems  Architecture  Considerations 

SE  activities  needed  to  complete  the  architecture  and  interrelate  the  operational 
and  systems  domains  are  developed  through  the  systems  performance  parameters,  with 
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the  integration  of  the  component  and  function  elements  as  a  basis  of  the  requirements 
(CORE  ADG,  2007).  The  components  with  respective  functions  are  derived  from  the 
operational  activities  needed  to  perform  the  mission.  The  example  component  type 
service  (see  Figure  29)  is  built  from  a  system  component  to  perform  a  service  function. 


Figure  29.  System  Architecture  component/function  relationship  example 

(From:  Vitech,  2007) 

8.  Components 

An  objective  of  the  system  architecture  is  to  identify  what  are  its  critical 
components  and  what  are  the  relationships  between  all  components  within  the  system. 
“Components  are  represented  in  CORE  as  physical  entities,  including  collections  of 
systems,  interfacing  systems,  and  entities  within  the  systems  architecture”  (CORF  ADG, 
2007).  The  components  identified  in  this  architecture  range  from  higher-level  systems 
like  “ship”  to  lower-level  individual  components  like  “Diver  davits.”  Each  component  is 
organized  within  the  Ship  Work  Breakdown  Structure  (SWBS),  displayed  in  Figure  30,  to 
define  and  categorize  to  boundaries  in  a  ship’s  systems  and  SoS. 
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Ship 

000 

General  Guidance  and 
Administration 

100 

Mull  Structure 

200 

Propulsion  Plant 

300 

Electric  Plant 

400 

Command  and 
Surveillance 

500 

Auxiliary  Systems 

600 

Outfit  and  Furnishings 

700 

Armament 

800 

Integration/ 

Engineering 

900 

Ship  Assembly  and 
Support  Systems 

Figure  30.  Ship  Work  Breakdown  Structure  (From;  MIL-HDBK-88 1,1998) 

A  work  breakdown  structure  (WBS)  provides  a  comprehensible  framework  for 
system  components  within  a  program.  It  organizes  the  components  in  terms  of 
hierarchically-related,  product-oriented  elements.  Improved  communication  in 
management  practices  will  be  directly  correlated  to  the  generation  of  a  WBS  throughout 
the  acquisition  process. 

The  foundation  for  WBSs  is  contained  in  DoD  Directive  5000.1  and 
DoD  Regulation  5000. 2-R.  (MlL-HDBK-881,  1998).  The  SWBS  structure  shown  in 
Figure  30  displays  the  ten  major  SWBS  subgroupings  that  serve  as  an  upper-level 
component  classification  for  the  towing  and  salvage  architecture.  All  towing-  and 
salvage-related  components  were  entered  into  CORE,  and  organized  into  their  respective 
SWBS  groupings. 
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9. 


Functions 


A  function  is  the  property  of  a  system  that,  when  performed,  will  fulfill  a 
requirement  for  an  objective.  Functions  are  decomposed  into  lower-level  functions  (see 
Figure  31),  until  the  individual  components  can  be  traced  to  a  particular  function  to  be 
performed.  Functions  are  based  on  requirements  that  can  be  identified  in  the  beginning 
stages  of  system  development  as  desired  characteristics.  The  functions  identified  for  the 
towing  and  salvage  platform  are  based  on  all  the  operational  activities  required  to  achieve 
the  missions  that  the  towing  and  salvage  community  is  required  to  perform. 


Figure  3 1 .  CORE  view  of  the  functional  decomposition  of 

“Conduct  Salvage  Operations” 


Functional  decomposition  refers  to  the  process  of  organizing  the  functional 
relationships  into  its  components  or  systems  for  the  purpose  of  defining  the  identity  of  the 
components.  Specifically,  what  function  must  be  provided  to  accomplish  the  mission 
requirements  and  how  will  that  function  be  fulfilled  by  use  of  a  system  component? 

10,  Functional  Requirements 

Requirements  are  the  basis  of  a  function  and  usually  specify  the  goals  of  the 
system.  “Requirements  development  occurs  when  operational  activities  and  performance 
characteristics  serve  as  sources  for  system  requirements”  (CORE  ADG,  2007). 
Operational  activities  lead  to  the  identification  and  definition  of  functional  requirements 
that,  when  added  to  the  identification  of  performance  characteristics,  results  in  system 
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requirements.  Thus,  a  requirement  is  a  result  of  an  operational  aetivity  and  a 
performanee  eharaeteristie,  as  displayed  in  Figure  31. 


Figure  32.  Requirements  generation  proeess  (From:  Viteeh,  2007) 

The  requirements  generated  from  a  eapability-need,  MBSE  methodology  are  a 
eomplete  set  of  requirements  that  will  be  a  basis  for  the  system  speeifieation  doeument. 
The  generated  requirements  were  eompared  with  the  given  set  of  requirements  from 
SUPSALV  (see  Table  8),  to  produee  a  eomparative  analysis  of  requirements-based 
system  modeling  versus  eapability-based  system  modeling. 


CHARACTERISTIC 

(THRESHOLD  OBJECTIVE) 

Speed  (knots  sustained) 

15/20 

Bollard  Pull  (toimes  i 

150;  T=0 

Navv  Persoimel  Accommodation 

42;  T=0 

Civilian  Crew  Acconmiodation 

15;  T=0 

Positioning  Mooring 

DP-2  DP-3.  +  4  Point  Moor;  T=0 

Endurance 

8.000  imi  @  8  kt  12.000  @10  kt 

Unobstnicted  Deck  Space;  AFT 

3600  ft-;  T=0 

Crane;  Lift  Capacity  Min.  110  Tonnes 

SWL 

(Amidsliips  Amidships  +  Stem) 

Crane:  FWD 

Min.  10  Tomies  SWL;  T=0 

Towing 

-  Twin  Dnim 

-  3"  wire  x  3.500  ft 

-  Traction  Winch 

-  Shark  Jaws 

-  Auto-tow  Pins 

•  Portable  Tow-bow 

R  &  A  Firefighting 

4  monitors  @  lOK  —  GPM  Min.  Each; 

AFFF  Capable;  T=0 

Interoperability 

Deck  Loading  and  Ship  Seivice 

Support  For: 

-  FMGS 

-  Deep  Ocean  Search  and  Recoveiy 

-  SAT-FADS 

-  SRDRS  (RCS  only  TUP  with  ADS) 

-  Submarine  Salvage  Support 

Table  8.  SUPSALV  Towing  and  Salvage  Platform  primary  requirements 

(From:  SUPSALV,  2007) 
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The  primary/critical  performance  requirements  given  by  SUPSALV  match  the 
high-level,  capability-based  requirements  that  were  generated  by  the  CORE  model-based 
SE  tool.  The  CORE  tool  can  produce  a  complete  capability-based  requirements  list,  with 
all  mission-based  functions  accounted  for  and  mapped  to  all  respective  lower-level 
components. 

11,  Nonfunctional  Requirements 

Nonfunctional  requirements  identify  criteria  that  can  be  used  to  evaluate  the 
system’s  operation  instead  of  identifying  specific  functions  or  behaviors  of  the  system. 
In  general,  nonfunctional  requirements  define  how  a  system  is  supposed  to  operate  rather 
than  what  it  is  supposed  to  do.  Nonfunctional  requirements  are  sometimes  referred  to  as 
“ilities,”  e.g.,  availability  and  survivability,  which  describe  the  criteria  in  which  the 
system  can  be  evaluated.  Within  the  CORE  architecting  tool,  nonfunctional  requirements 
are  not  present  within  the  schema,  but  are  present  within  requirement  class  with  the  type 
attribute  set  to  “Constraint.” 

The  process  starts  with  extracting  the  originating  requirements  into  the 
requirements  class  and  then  set  the  “type”  attribute  to  (Functional,  Performance, 
Constraint,  or  Verification).  A  Functional  requirement  will  be  modeled  with  “Function” 
and  the  nonfunctional  requirements  (except  for  performance)  will  be  addressed  by  one  of 
the  specialty  engineering  disciplines. 

Nonfunctional  requirements  will  be  clearly  defined  and  utilized  when  creating  a 
simulation  based  on  the  CORE  model.  The  availability  and/or  survivability  of  a  system 
cannot  be  determined  without  being  able  to  simulate  all  of  the  components  working 
together  within  an  SoS,  to  include  the  environment. 

D,  TOWING  AND  SALVAGE  SPECIFIC  METHODOLOGY 

The  CORE  architecture  schema  has  many  other  elements  which  connect  with  and 
influence  the  interoperability  of  the  architecture.  The  focus  has  been  on  the  major 
elements  which  directly  influence  the  capabilities  of  the  system  based  on  the  previously 
defined  mission.  The  major  elements  focused  on  in  this  thesis,  when  completed,  generate 
the  necessary  architectural  views  that  will  lay  the  foundation  for  the  future  towing  and 
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salvage  platform  architecture.  These  elements,  along  with  the  architecture  process  steps 
taken  for  a  comprehensive  architectural  view  development,  are  displayed  in  Figure  33. 


CORE  Architecture  Process 


Component 
Step  6: 

Define  the  Components 
Necessary  that  will  perform 
The  functions. 


OPEFh^TIONAL 

ACTIVITIES 


Implemented  by 


Operational  Activities  ^ 

Step  3: 

Define  the  Operational  Activities 
Or  Capabilities  required  to  achieve 
The  mission 


FUNCTION  k - 


Decomposed  by 


Function 
Step  5: 

Define  the  Functions  that  are  implemented 
By  the  Operational  Activities  in  order  to  achieve 
The  mission 


Refined  by 


Requirements 
Step  7: 

Define  the  Functional  Requirements  based  on 
Capability  need. 


Figure  33.  Methodology  for  CORE  Towing  and  Salvage  architecture  development 

The  steps  taken  in  the  architecture  process  displayed  in  Figure  33  are  based  on  a 
methodology  built  from  the  DRM  capability  need.  The  mission  requirements  are 
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generated  by  a  DRM  that  would  require  the  combined  capabilities  of  both  towing  and 
salvage  platforms.  Beginning  with  defining  the  architecture,  the  DRM  was  developed  to 
incorporate  the  full  functional  potential  of  the  towing  and  salvage  activities.  The  next 
step  in  the  process  was  to  define  the  operational  activities  necessary  to  achieve  the 
identified  mission  requirements,  as  well  as  link  them  to  the  operational  nodes  responsible 
for  conducting  those  activities.  The  activities  are  also  built  from,  and  decomposed  by, 
the  standardized  operational  tasks  linked  to  the  individual  mission  tasks.  Once  the 
activities  are  identified,  a  functional  requirements  generation  process  is  initiated,  based 
on  a  functional  hierarchy  from  the  components  necessary  to  complete  the  mission  tasks. 
Finally,  all  elements  are  then  redefined,  decomposed,  and  linked  to  their  schema 
element  relationships. 

The  proper  development  of  an  integrated  towing  and  salvage  architecture  requires 
a  comprehensive  modeling  technique  based  on  well-specified,  capability-based 
requirements.  To  properly  guide  architecting,  design,  and  integration  of  this  diversity  of 
system  elements,  we  have  developed  a  comprehensive  towing  and  salvage  SoS 
architecting  method  that  addresses  all  facets  of  the  mission  capabilities  of  the  proposed 
SoS,  such  that  it  will  fully  meet  the  needs  of  the  towing  and  salvage  community 
(Whitcomb,  2008).  The  convergence  of  SoS  engineering  with  CORE  architecting 
techniques  will  lead  to  a  system  definition  incorporating  all  desired  capabilities  of  the 
system,  with  considerations  to  utilize  commercial  towing  and  salvage  capabilities. 

The  architecting  of  the  towing  and  salvage  SoS  starts  with  the  transformation  of 
an  operational  capability  need,  based  on  mission  requirements,  into  a  set  of  functional 
and  physical  requirements  that  are  used  to  guide  the  development  of  operational  and 
system  architectures.  This  process  establishes  a  set  of  physical  requirements  to  which  the 
future  towing  and  salvage  platform  can  be  defined.  Essentially,  without  a  comprehensive 
architecture  based  on  mission  requirements  that  includes  a  well-developed  set  of 
specifications,  an  integrated  SoS  cannot  be  successfully  realized  (Whitcomb,  2008). 

E,  SUMMARY 

The  SE  process  was  defined  in  Chapter  I  without  any  focus  on  capability-based 

architecting.  This  thesis  has  defined  the  need  for  recognizing  the  capabilities  based  on 
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mission  requirements.  The  need  for  MBSE  has  also  been  recognized  and  a  model-based 
architecting  process  has  been  developed,  based  on  the  fusion  of  SE  and  systems 
architecting.  The  differences  between  SE  and  systems  architecting  have  been 
established,  showing  the  benefits  of  what  each  can  bring  to  a  system  design.  Eigure  34 
displays  the  collective  approach  of  the  MBSE  process  developed  in  this  thesis  to  include: 

•  Capability  need  recognition. 

•  Customer  need/desired  capabilities  input. 

•  Typical  SE  process. 


•  CORE  architecture  design  process. 


Eigure  34.  Composite  MBSE  process 

Euture  T-ARS(X)  operations  will  require  an  unprecedented  level  of  integration 
among  joint  towing  and  salvage  capabilities.  The  towing  and  salvage  community’s 
increased  demand  for  a  mission-tailored  future  salvage  platform  requires  a  more 
integrated  approach  to  T-ARS(X)  requirements  generation.  Along  with  a  towing  and 
salvage  force  simulation,  MBSE  can  achieve  a  comprehensive  platform  design  for  either 
build  or  buy  recapitalization  strategy. 
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V.  ARCHITECTURE  RESULTS 


A,  DoDAF  VIEWS 

The  DoDAF  is  described  in  detail  in  Chapter  I  and  its  views  will  be  demonstrated 
in  this  chapter.  As  described  earlier,  the  DoDAF  displays  and  organizes  a  complex 
systems  architecture  into  consistent  views,  showing  interoperability  within  the  system 
elements.  Representations  for  the  DoDAF  products  are  drawn  from  the  diagramming 
technique  Entity-Relationship  Diagrams  (ERDs),  found  in  the  CORE  model.  The 
different  architecture  views,  along  with  the  view  descriptions,  are  displayed  in  Table  9. 
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Table  9.  DoDAF  architecture  views  descriptions  (DODAF,  2004) 
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CORE  documents  the  arehiteeture  produet  as  a  Rieh  Text  Format  (RTF),  via 
seripts  that  generate  a  standard  DoDAF  diagram.  The  DoDAF  version  F5  view  seripts 
are  designed  to  be  flexible  in  order  to  support  any  later  iteration  (Viteeh,  2007).  Figure 
35  displays  the  integration  of  the  SE  proeess  steps  with  eaeh  DoDAF  view  produetion 


ability  based  on  time. 


Requirements  Analysis 


5.  Develop  the  Operational  Context 


9.  AllocitHTuni 


10.  PrepafBTfiter^~^^agratSV-^ 
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11.  Define  Resources,  En'or  Detection  &  Recovery 


13.  Develop  Operationat  Demonstration  Master  Plan  ^ 


16.  Generate  Operational  and  System  Architecture  Graphics,  Briefings  and  Reports 


□  Functional  Analysis 


Synthesis 

System  Analysis 
and  Control 


6.  Develop  Operational  Scenarios 


7.  Derive  Functional  Behavior 


15.  Conduct  Trade-off  Analyses 


Figure  35.  CORE  integration  of  the  typieal  systems  engineering  process  with  DoDAF 

views  milestones  (From;  Viteeh,  2008) 

From  an  SE  perspective,  the  DoDAF  architecture  views  OV-2,  OV-5,  and  SV-4 
are  the  most  important  views  because  they  lay  the  foundation  for  the  operational 
architecture  (structure,  behavior,  interfaces)  and  provide  a  basis  for  developing  the 
system  architecture.  For  the  purpose  of  this  thesis,  the  OV-2,  OV-5,  and  SV-4  are 
developed  and  discussed.  A  System  Design  Document  (SDD)  is  added  for  referenee  in 
Appendix  A. 

The  SDD  deseribes  how  the  functional  and  nonfunctional  requirements  and 
CONORS  are  transformed  into  system  design  specifications.  The  SDD  developed  with 
this  architecture  is  a  high-level,  first-iteration  example  in  order  to  document  and  display 
the  system  design  through  detailed  design  specifications.  The  SDD  gives  a  high-level 
overview  of  the  system  architecture  and  is  a  formal  documentation  process  for 
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requirements  generation  that  ean  be  used  to  design  the  new  towing  and  salvage  platform. 
More  eomponent-specifie  results  ean  be  obtained  from  the  SDD,  which  was  also  used  as 
the  detailed  design  reference  for  requirements  generation.  These  requirements  were 
compared  to  the  current  commercial  market  capabilities  outlined  in  Appendix  B. 

Operational  views  detail  the  user’s  operating  domain  in  which  the  developing 
system  will  operate  (Zachman,  2007).  The  OV-2  is  an  operational  node  connectivity 
description,  which  displays  the  relationships  between  the  nodes  as  well  as  organizes  the 
nodes  into  an  operational  hierarchy.  The  operational  node  relationship  hierarchy  from 
SEA  OOC  is  displayed  in  Figure  36. 


Figure  36.  SEA  OOC  SV-2  architecture  view 

The  OV-5  DoDAF  view  is  an  activity  model  that  identifies  and  displays  the 
hierarchical  decomposition  of  an  operational  activity,  as  well  as  show  the  relationships 
between  the  capabilities  and  activities  in  which  each  activity  is  interconnected.  The 
OV-5  Activity  Model  for  Conduct  Towing  and  Salvage  DRM  hierarchy  is  displayed  in 
Figure  37. 
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Figure  37.  “Conduct  Towing  and  Salvage  DRM”  Hierarchy  Diagram 

The  Conduct  Towing  and  Salvage  DRM  IDEFO  diagram  illustrates  the  children  or 
offspring  operational  activities  with  the  user-selected  operational  nodes.  This  operational 
activity  model  graphically  organizes  the  activities  in  a  hierarchy,  clarifying  the  level  at 
which  each  function  is  required.  Figure  38  is  the  IDEFO  diagram,  depicting  which 
operational  nodes  perform  the  “Conduct  Towing  and  Salvage  DRM”  operational 
activities.  The  overlap  within  the  activities  demonstrates  the  actions  performed  by  the 
operational  nodes. 
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SEA  OOC 


Figure  38.  “Conduct  Towing  and  Salvage  DRM”  IDEFO  Diagram 

Within  the  OV-5,  each  of  the  children  operational  activities  can  be  analyzed, 
along  with  their  activity  relationships  among  their  corresponding  operational  nodes. 
Figure  39  displays  the  IDEFO  diagram  of  the  “Salvage”  operational  activity. 
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SEA  OOC 


Figure  39.  “Salvage”  IDEFO  Diagram 

The  DoDAF  system  and  service  view  is  a  set  of  graphical  products  that  describe 
systems  and  interconnections  that  support  DoD  functions.  SV  products  focus  on  specific 
systems  with  specific  physical  locations.  “The  relationship  between  architecture  data 
elements  across  the  SV  to  the  OV  can  be  exemplified  as  systems  are  procured  and  fielded 
to  support  organizations  and  their  operations”  (DoDAF,  2007).  The  system  and  service 
view  focused  on  in  this  thesis  is  the  SV-4  view,  which  documents  the  system  data  flows 
between  functions.  Figure  40  displays  the  SV-4  hierarchy  for  the  function  “Conduct 
Towing  Operations.”  When  developing  a  complete  architecture,  the  level  of  detail  from  a 
functional  decomposition  within  the  SV  views  will  ensure  sufficient  system  design. 
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Figure  40.  “Conduct  Towing  Operations”  Hierarchy  Diagram 


This  SV-4  documents  the  functional  relationships  of  just  one  of  the  functions 
within  the  system  and  can  be  expanded  to  include  all  system  functions.  The  “Conduct 
Towing  Operations”  function  can  be  displayed  with  the  component  relationships 
necessary  to  achieve  the  functional  requirement.  The  IDEFO  context  diagram  is 


displayed  in  Figure  41. 


4.0  Conduct 
towing  operations 


4.3.2  Powhaten  Cla' 


1.5  Afc 


1.451  Pilot  House 
.  ^  Ai  to-tow  pins 
Bov7  Tlmistei 

Co  luiuun  ic  ations  ec|u  ip  nient 
Conq  ollable  Reversible  Pitch  Propellei 
Deck  Lighting 
Fuei  system 
Hyclraulif  Power  Packs 

OOC2  Salvage  and  Towing  Assets 
Poi  table  Bullwarks 
Tow  Fair  leads 
Portable  Tow  Bow 
Rope  Transport  Tray 


Figure  41 .  “Conduct  Towing  Operations”  IDEFO  A-0  Context  Diagram 
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The  SV-4  function  can  be  decomposed,  showing  the  functional  breakdown  of  the 
“Conduct  Towing  Operations”  function  with  the  component-to-function  individual 
relationships.  Figure  42  displays  the  IDEFO  diagram  of  the  functions  necessary  to 
perform  the  “Conduct  Towing  Operations”  function. 


Figure  42.  “Conduct  Towing  Operations”  IDEFO  Diagram 

From  the  DoDAF  views  generated  in  this  thesis,  a  ship  can  begin  a  preliminary 
design  phase  based  on  the  requirements  generated  with  function-to-component 
relationships  defined.  Table  8  displays  the  top-level  requirements  desired  by  the  program 
manager,  based  on  current  ARS/T-ATF  capabilities  for  potential  future  mission  needs. 
The  customer’s  desires  and  system  requirements  have  been  identified  and  verified  to 
achieve  a  combined  towing  and  salvage  mission.  Eower-level  requirements  generation 
must  be  developed  in  order  to  generate  a  complete  analysis  of  the  buy  versus  build 
options.  A  top-level  commercial  market  analysis,  mapping  the  capabilities  to  the 
architecture  as  an  analysis  of  alternatives,  is  demonstrated  below.  In  the  CORE  schema, 
these  commercial  capabilities  are  captured  as  resources  for  a  potential  T-ARS(X) 
simulation. 
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B.  COMMERCIAL  TOWING  AND  SALVAGE  MARKET  ANALYSIS 

Figure  43  displays  the  top-level,  T-ARS(X)  requirements  compared  to  the  current 
commercial  capabilities.  Not  all  desired  or  derived  requirements  were  analyzed  due  to 
the  level  of  focus  needed  to  outline  the  method  implemented  in  this  thesis.  These 
requirements  were  deemed  critical  or  mission  essential  because  if  any  of  the  selected 
requirements  cannot  be  met,  based  on  T-ARS(X)  mission  need  as  mapped  in  the 
architecture,  the  joint  towing  and  salvage  capability  cannot  be  achieved. 


Vessels  of  Opportunity 
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Figure  43.  Commercial  capabilities  with  requirements  comparison 

The  vessels  of  opportunity  are  derived  from  a  complete  list  of  available 
commercial  platforms  and  are  considered  to  be  the  closest  match  to  the  generated 
requirements.  All  cells  highlighted  in  blue  either  meet  the  requirement  or  surpass  the 
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lower  limit  of  the  requirement.  Yellow  is  elose  and  ean  be  improved,  while  red  will  not 
meet  the  requirement,  even  with  improvements.  Bollard  pull  and  crane  lift  capacity  are 
two  contracting  requirements  that  seem  impossible  to  met  simultaneously.  Bollard  pull, 
defined  in  Chapter  II,  is  the  ability  of  a  vessel  to  tow  a  certain  weight.  Not  all  of  these 
platforms  are  designed  to  tow,  but  have  the  ability  if  configured  correctly.  The  platforms 
that  do  not  have  ample  crane  lift  ability  can  be  configured  with  an  additional  crane  to 
meet  that  requirement. 

All  of  the  desired  performance  requirements/characteristics  are  based  on  a 
perceived  mission  need  and  were  documented  as  an  estimate  of  future  use.  CORE  can 
provide  accurate  requirements  documentation  based  on  mission  need.  Components  are 
the  lower-level  elements  of  the  architecture  which  is  based  on  a  defined  mission 
described  in  Chapter  III.  The  functions  are  performed  by  components  and  are  necessary 
to  achieve  the  mission  capability.  The  SUPSALV  desired  characteristics  are  verified  to 
fulfill  a  mission  need  in  CORE.  Table  10  displays  how  each  desired  T-ARS(X) 
characteristic  should  be  architected. 
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Desired  Performance 
Characteristics 

Characteristic 

(Threshhold/Ohj  ective) 

Should  he  obtained  from  a 
MBSE  architecture 

Speed 

15/20 

Based  on  sea  basing/DRM 

Bollard  Pull 

125/175 

Based  on  function 
implements  capability 

Navy  Personnel 
Accomodation 

42;  T=0 

Based  on  component 
architecture  simulation 

Civilian  Crew 
Accomodation 

15;  T=0 

Based  on  component 
architecture  simulation 

Positioning 

DP-2/DP-3 

Standard  ship  system 
requirement 

Endurance 

8,000  nm  @  8  kt  /  12,000  @  10  kt 

Based  on  sea  basing/DRM 

Unobstructed  Deck 
Space;  Aft 

3600  sqft/4300  sqft 

Based  on  mission  needs 

Crane;  Lift  Capacity 

120  short  tons  SWL 

Based  on  function 
implements  capability 

Crane;  Fwd 

10  short  tons  SWL;  T=0 

Based  on  function 
implements  capability 

Ice  Classification 

ABS  Ice  Class  CO;  T=0 

Based  on  sea  basing/DRM 

Stability 

Adequate  metacentric  height,  30  yr 
service  life 

Standard  ship  system 
requirement 

Unobstructed  Deck 
Space;  Fwd 

720  sqft;  T=0 

Based  on  mission  needs 

Survivability 

Commercial  Salvage  Standards, 
ABS  Classification 

Standard  ship  system 
requirement 

Table  10.  Desired  performance  requirements  mapping  process 


Based  on  the  analysis  of  the  commercial  market  compared  to  the  MBSE- 
generated  requirements,  a  top-level  system  design  with  consideration  of  available 
capabilities  has  been  developed.  The  architecting  process,  with  implied  T-ARS(X) 
characteristics,  has  been  mapped  to  a  verifiable  set  of  requirements  for  future  ship  design. 
The  results  indicate  a  gap  in  bollard  pull  and  crane  lift  capacity  for  commercial  platforms. 
The  final  step  in  this  analysis  would  be  to  analyze  the  cost  comparison  of  outfitting  the 
missing  requirements  on  the  commercial  platforms  with  building  a  new  platform. 

C.  SUMMARY 

The  architecture  demonstrated  in  this  chapter  highlight  some  of  the  more 

important  DoDAF  views,  but  they  barely  scratch  the  surface  of  the  potential  towing  and 
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salvage  architecture  development  available  in  the  CORE  modeling  tool,  for  a  final  SoS 
development.  The  SDD  in  Appendix  A  is  one  of  many  official  documents  that  be 
produced  by  the  push  of  a  button,  once  the  elements  have  been  completed  and  linked 
accordingly.  Capabilities-based  architecting  approach  for  the  recapitalization  of  the 
future  towing  and  salvage  platform  has  been  demonstrated,  providing  a  high-level/ 
first-iteration  of  requirements  generation. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


While  the  Navy  continues  its  internal  debate  on  which  direction  to  pursue 
for  surface  ships,  the  service  has  begun  to  lay  down  the  ground  work, 
schedules  and  goals  for  implementing  open  systems  architecture  in  order 
to  reduce  the  cost  and  speed  up  the  time  cycle  for  delivering  capabilities  to 
warfighters  (Fein,  2008). 

A,  CONCLUSIONS 

The  Navy  has  been  analyzing  the  process  of  how  to  require  open  architecture  in 
new  contracts.  The  DoD  has  changed  their  philosophy  of  stove-pipe  design  to 
developing  integrated  architectures  based  on  capability  needs.  Along  with  the  JCIDS 
process,  the  DoDAF  and  NAERG  provide  a  basis  for  defining  standard  architecture 
elements  for  future  SoSs.  As  the  Navy  changes  its  approach  to  developing  new  SoSs 
from  capability  need,  a  standard  SoS  architecting  process  definition  is  required. 

What  has  been  demonstrated  in  this  thesis  is  an  systems  architecting  approach  that 
is  not  only  traceable  from  a  realizable  mission  need,  to  top-level  system  requirements,  to 
system  function  and  components,  but  provides  a  fully  interconnected  relationship  among 
all  architectural  elements.  An  architecture  was  created  that  can  be  revised,  rerun,  and 
moved  around  in  an  interactive  manner  in  order  to  explore  the  design  space  of  a 
comprehensive  and  efficient  system  design.  The  recapitalization  of  a  towing  and  salvage 
vessel  was  used  as  an  objective  or  need  to  define  an  architecting  process.  The 
architecture  process  was  an  interactive  methodology  using  the  CORE  DoDAE  E5  schema 
to  produce  necessary  architecture  views  and  design  documents.  This  process  provides  a 
useful  methodology  to  demonstrate  the  capabilities  needed  by  the  towing  and  salvage 
community  for  joint,  towing,  and  salvage  operations. 

This  thesis  outlined  the  first-iteration  of  a  MBSE  process,  illustrating  the  manner 
of  how  an  SoS  is  engineered  in  the  context  of  an  architecture.  The  CORE  architecting 
tool  was  utilized  to  develop  an  SDD,  as  well  as  key  DoDAF  views  for  consistent  and 
complete  requirements  generation,  based  on  towing  and  salvage  capability  needs. 
High-level  functional  and  nonfunctional  requirements  were  developed  and  compared 
with  the  requirements  generated  by  SUPSALV  for  optimum  future  platform  performance 
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characteristics.  The  consolidated  requirements  were  then  eompared  to  the  commercial 
market  for  future  analytieal  development  of  reeapitalization  strategies. 

From  a  top-level  requirements  view,  the  eommereial  market  has  vast 
opportunities  for  a  potential  future  U.S.  Navy  eombined  towing  and  salvage  platform. 
The  two  key  requirements  that  prohibit  an  immediate  and  eomplete  eomparison  between 
U.S.  Navy  needs  and  eommereial  market  eapabilities  are  erane  ratings  and  bollard  pull. 
Commereial  ships  were  designed  for  either  heavy-lift-salvage  and  diver  interoperability 
or  they  were  designed  for  towing  large  vessels.  A  eombined-eapability  commereial 
platform  eould  be  redesigned  or  outfitted  with  the  missing  capability.  The  eost  of 
developing  a  eommereial  replacement  vessel  should  be  explored  further. 

The  U.S.  Navy  towing  and  salvage  community  can  benefit  from  an  open, 
integrated  arehitecture  model  of  a  eomplete  system,  based  on  the  eapability-need  from 
mission  requirements.  Using  the  data  from  the  UNTL,  NAERG,  and  towing  and  salvage 
CONOPS,  a  eombined  platform  ean  be  realized  with  a  logieal  and  eomplete  set  of 
requirements,  modeled  after  what  is  needed  viee  what  is  already  utilized. 

B,  RECOMMENDATIONS 

The  need  for  a  towing  and  salvage  eommunity  analysis  of  a  build  or  buy  ship 
reeapitalization  strategy  substantiates  the  need  for  a  eomprehensive  simulation  of 
eapabilities.  The  two  main  objeetives  to  the  analysis  are: 

1 .  Independent  towing  and  salvage  platforms  or  single-hull 

eombined  capability. 

2.  Build  the  future  platform  or  purehase  from  the  commercial  community. 

To  satisfy  the  objeetives,  an  analysis  of  future  mission  needs  must  be  condueted, 

along  with  a  market  analysis  of  the  eommereial  ships  with  eost  estimates  on 
improvements.  The  need  for  an  arehiteeture  model  that  eontains  all  towing  and  salvage 
information,  ineluding  all  required  tasks  and  potential  eomponents,  must  be  developed. 
Onee  a  eomprehensive  model  has  been  built,  a  simulation  must  be  eondueted  to  inelude 
seenarios  that  utilize  single-hull  towing  and  salvage  platforms,  as  well  as  independent 
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platforms.  The  development  of  the  overall  diving  and  salvage  arehitecture,  and  the 
simulation  of  the  use  of  the  architeeture  for  strategie  and  operational  deeision  making 
should  be  accomplished.  This  includes: 

•  Developing  an  architecture  that  is  populated  to  the  extent  that  elements 
include  enough  description  to  demonstrate  the  use  for  operational  and 
strategic  planning,  including  the  need  for  trade-offs  for  acquiring  new 
platforms  or  contracting  of  outside  resources  (Whitcomb,  2008). 

•  Exercising  the  architecture  in  a  dynamic  sense  to  create  options  for 
planning  and  design  (Whitcomb,  2008). 

•  Integrating  the  architecting  process  and  respective  tools  (e.g.,  CORE)  with 
ship  design  tools  (e.g.,  ASSET,  POSSE)  in  order  to  allow  a  more 
quantitative,  physics-based  analysis  of  ship  platform  development,  and 
connect  the  traditional  ship  design  process  to  the  stakeholder’s  need 
(Whitcomb,  2008). 

•  Expanding  the  process  scope  to  core  warfighting  capabilities  and  business 
capabilities,  such  as  combatant  ships,  aircraft,  ground  vehicles,  and  system 
command  organizations  (Whitcomb,  2008). 

•  Utilizing  and  incorporating  all  task  lists  to  include  the  UNTL,  UJTE,  and 
NMETE,  with  real-time  updates  as  missions  get  redefined. 

•  Revising  the  CORE  schema  to  include  a  separate  capabilities  element, 
which  links  operational  activities  to  the  architecture  illustrating  the 
process;  the  architecture  is  composed  of  capabilities  that  achieve 
operational  activities. 

Continuing  the  development  of  a  standard  architecting  process,  which  will 
facilitate  the  implementation  of  a  future  towing  and  salvage  capability,  is  critical  to 
acquiring  an  efficient  system  built  specifically  to  meet  the  community’s  needs.  The 
success  of  a  standard  architecting  process  will  lead  to  Navy-wide  open  architecture 
implementations  for  system  development,  thus  reducing  costs  and  maximizing  efficiency 
throughout  the  Elect. 
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APPENDIX  A 


SYSTEM  DESCRIPTION  DOCUMENT 

FOR 

T-ARS(X) 


Thursday,  September  04,  2008 


Prepared  For: 

Naval  Postgraduate  School,  Systems  Engineering  Department 


Prepared  By: 
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T-ARS(X) 

Allocated  Functions: 

1.0  Move  through  the  water 

1 . 1  Produce  propulsive  power  to  achieve  sustained  speed 

1.2  Provide  porpulsive  power  at  usable  speed  (rpm) 

1.3  Transfer  power  to  water 

1.4  Control  speed  and  direction  of  movement  locally 

1.5  Control  speed  and  direction  of  movement  remotely 
10.0  Conduct  pollution  response 

10.1  Provides  Pollution  Logistics  support 
1 1.0  Conduct  Pollution  Training 

13.0  Conduct  Diving  Operations  other  than  salvage 
14.0  Conduct  Personnel  Rescue  Operations 
15.0  Conduct  Underway  Replinishment  Operations 
2.0  Maintain  Desired  Course 

2. 1  Determine  if  course  is  safe 

2.2  Alter  existing  course 

2.3  Maneuver  alongside  pier 
3.0  Conduct  Salvage  Operations 

3.1  Conduct  Collision  Repair 

3.1  Conduct  diving  Operations 

3.1.1  Conduct  Underwater  Inspections 

3.1.2  Conduct  Underwater  Welding 

3.2  Conduct  Ocean  Search  and  Recovery 

3.2.1  Conduct  Heavy  Lift  Operations 

3.3  Retrieve  vessel  from  beach 

3.3  Transport/secure  salvaged  system  or  equipment 
4.0  Conduct  towing  operations 

4. 1  Connect  tow  line  to  vessel 

4.2  Position  ship  for  towing  operations 

4.3  Tow  vessel  through  water 

5.0  Conduct  sustained  operations  underway 

5. 1  Ensure  habitable  conditions 

5.2  Maintain  equipment  in  operating  condition 

5.3  Communicate  information 

5.4  Combat  damage 

5.5  Secure  Condition  while  underway 

5.6  Secure  position  while  in  port 

5.7  Provide  electrical  power 

5.8  Provide  fuel  source 

6.0  Operate  on  surface  of  water 

6. 1  Enclose  personnel  and  equipment 

6.2  Support  total  ship  weight 

6.3  Minimize  total  resistance 
7.0  Maintain  Desired  Position 

7. 1  Anchor  ship  to  seafloor 
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7.2  Control  Dynamic  Positioning  system 

7.3  Moor  Ship  to  Object 

8.0  Conduct  beach  retraction  operations 
9.0  Conduct  Firefighting  Operations 

Assigned  Design  Constraints: 

Salvage  Equipment  Stowage  Space 
Unobstructed  Deck  Space;  Aft 
Unobstructed  Deck  Space;  Fwd 

Specified  Performance  Objectives: 

Bollard  Pull 
Endurance 

Firefighting  Flow  Rate 
Primary  Crane  Eift  Capacity 
Secondary  Crane  Eift  Capacity 
Speed 


Figure  1  T-ARS(X)  Physical  Context 


4.3.2  Powhaten 
Class:  T-ATF  166 


nil 


4.3.4  Safeguard 
Class:  ARS  50 


nil 


T-ARS(X) 


nil 


Figure  2  T-ARS(X)  Physical  Interface  Context 
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2  Originating  Requirements 


Bollard  Pull 

Basis  Of: 

Function:  3.3  Retrieve  vessel  from  beach 
Function:  4.0  Conduct  towing  operations 
Function:  4.3  Tow  vessel  through  water 

Specifies: 

Component:  T-ARS(X) 

Civilian  Crew 

Basis  Of: 

Function:  5.1  Ensure  habitable  conditions 
Specifies: 

Component:  T-ARS(X) 

Dynamic  Positioning 

Basis  Of: 

Function:  2.3  Maneuver  alongside  pier 
Function:  3.0  Conduct  Salvage  Operations 
Function:  3.1  Conduct  diving  Operations 
Function:  3.2  Conduct  Ocean  Search  and  Recovery 
Function:  3.2.1  Conduct  Fleavy  Lift  Operations 
Function:  3.2.2  Conduct  ROV  operations 
Function:  4.2  Position  ship  for  towing  operations 

Specifies: 

Component:  T-ARS(X) 

Firefighting  Flow  Rate 

Basis  Of: 

Function:  9.0  Conduct  Firefighting  Operations 
Specifies: 

Component:  T-ARS(X) 

Ice  Classification 

Basis  Of 

Function:  1 .0  Move  through  the  water 
Specifies: 

Component:  T-ARS(X) 

Navy  Personnel  Accomodation 

Basis  Of: 

Function:  5.1  Ensure  habitable  conditions 
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2  Originating  Requirements 


Specifies: 

Component:  T-ARS(X) 

Primary  Crane  Lift  Capacity 

Basis  Of: 

Function:  3.0  Conduct  Salvage  Operations 
Function:  3.2. 1  Conduct  Fleavy  Lift  Operations 

Specifies: 

Component:  T-ARS(X) 


Salvage  Equipment  Stowage  Space 


Basis  Of 
Function: 
Function: 
Function: 
Function: 


3.3  Transport/secure  salvaged  system  or  equipment 

6.1  Enclose  personnel  and  equipment 
Maintains  equipment 
Provides  equipment/supplies 


Specifies: 

Component:  T-ARS(X) 


Secondary  Crane  Lift  Capacity 


Basis  Of: 

Function:  3.0  Conduct  Salvage  Operations 
Function:  3.2  Conduct  Ocean  Search  and  Recovery 
Function:  3.2.1  Conduct  Fleavy  Lift  Operations 
Function:  3.2.2  Conduct  ROV  operations 


Specifies: 

Component:  T-ARS(X) 


Speed 


Basis  Of: 
Function: 
Function: 
Function: 
Function: 
Function: 
Function: 


1.0  Move  through  the  water 

1 . 1  Produce  propulsive  power  to  achieve  sustained  speed 

1 .2  Provide  porpulsive  power  at  usable  speed  (rpm) 

1.3  Transfer  power  to  water 

1.4  Control  speed  and  direction  of  movement  locally 

1.5  Control  speed  and  direction  of  movement  remotely 


Specifies: 

Component:  T-ARS(X) 


Unobstructed  Deck  Space;  Aft 

Basis  Of: 

Function:  3.0  Conduct  Salvage  Operations 

Function:  3.3  Transport/secure  salvaged  system  or  equipment 
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2  Originating  Requirements 


Specifies: 

Component:  T-ARS(X) 

Unobstructed  Deck  Space;  Fwd 

Basis  Of: 

Function:  3.0  Conduct  Salvage  Operations 

Function:  3.3  Transport/secure  salvaged  system  or  equipment 

Specifies: 

Component:  T-ARS(X) 
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3  Design  Constraints 


Salvage  Equipment  Stowage  Space 

Constrains: 

Component:  T-ARS(X) 

Unobstructed  Deck  Space;  Aft 

Constrains: 

Component:  T-ARS(X) 

Unobstructed  Deck  Space;  Fwd 

Constrains: 

Component:  T-ARS(X) 
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10  Components 


Bollard  Pull 

Specifies: 

Component:  T-ARS(X) 

Endurance 

Specifies: 

Component:  T-ARS(X) 

Function:  1 .0  Move  through  the  water 

Firefighting  Flow  Rate 

Specifies: 

Component:  T-ARS(X) 

Primary  Crane  Fift  Capacity 

Specifies: 

Component:  T-ARS(X) 

Secondary  Crane  Fift  Capacity 

Specifies: 

Component:  T-ARS(X) 

Speed 

Specifies: 

Component:  T-ARS(X) 


Part  I  -  Hierarchical  Function  List 


1 .0  Move  through  the  water 
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10  Components 


1 . 1  Produce  propulsive  power  to  achieve  sustained  speed 

1 .2  Provide  porpulsive  power  at  usable  speed  (rpm) 

1.3  Transfer  power  to  water 

1 .4  Control  speed  and  direction  of  movement  locally 

1.5  Control  speed  and  direction  of  movement  remotely 

1 . 1  Produce  propulsive  power  to  achieve  sustained  speed 

1 .2  Provide  porpulsive  power  at  usable  speed  (rpm) 

1.3  Transfer  power  to  water 

1 .4  Control  speed  and  direction  of  movement  locally 

1.5  Control  speed  and  direction  of  movement  remotely 
10.0  Conduct  pollution  response 

10.1  Provides  Pollution  Logistics  support 
1 1.0  Conduct  Pollution  Training 

13.0  Conduct  Diving  Operations  other  than  salvage 
14.0  Conduct  Personnel  Rescue  Operations 
15.0  Conduct  Underway  Replinishment  Operations 
2.0  Maintain  Desired  Course 

2.1  Determine  if  course  is  safe 

2.2  Alter  existing  course 

2.3  Maneuver  alongside  pier 

2.1  Determine  if  course  is  safe 

2.2  Alter  existing  course 

2.3  Maneuver  alongside  pier 
3.0  Conduct  Salvage  Operations 

3.1  Conduct  Collision  Repair 

3.1  Conduct  diving  Operations 

3.1.1  Conduct  Underwater  Inspections 

3.1.2  Conduct  Underwater  Welding 

3.2  Conduct  Ocean  Search  and  Recovery 

3.2.1  Conduct  Heavy  Lift  Operations 

3.2.2  Conduct  ROV  operations 

3.3  Retrieve  vessel  from  beach 

3.1  Conduct  Collision  Repair 

3.1  Conduct  diving  Operations 

3.1.1  Conduct  Underwater  Inspections 

3.1.2  Conduct  Underwater  Welding 

3.1  Conduct  diving  Operations 

3.1.1  Conduct  Underwater  Inspections 

3.1.2  Conduct  Underwater  Welding 

3.2  Conduct  Ocean  Search  and  Recovery 


101 


10  Components 


3.2. 1  Conduct  Heavy  Lift  Operations 

3.2.2  Conduct  ROV  operations 

3.2.1  Conduct  Heavy  Lift  Operations 

3.3  Retrieve  vessel  from  beach 

3.3  Transport/secure  salvaged  system  or  equipment 
4.0  Conduct  towing  operations 

4. 1  Connect  tow  line  to  vessel 

4.2  Position  ship  for  towing  operations 

4.3  Tow  vessel  through  water 

4.1  Connect  tow  line  to  vessel 

4.2  Position  ship  for  towing  operations 

4.3  Tow  vessel  through  water 

5.0  Conduct  sustained  operations  underway 

5.1  Ensure  habitable  conditions 

5.2  Maintain  equipment  in  operating  condition 

5.3  Communicate  information 

5.4  Combat  damage 

5.5  Secure  Condition  while  underway 

5.6  Secure  position  while  in  port 

5.7  Provide  electrical  power 

5.8  Provide  fuel  source 

5.1  Ensure  habitable  conditions 

5.2  Maintain  equipment  in  operating  condition 

5.3  Communicate  information 

5.4  Combat  damage 

5.5  Secure  Condition  while  underway 

5.6  Secure  position  while  in  port 

5.7  Provide  electrical  power 

5.8  Provide  fuel  source 

6.0  Operate  on  surface  of  water 

6.1  Enclose  personnel  and  equipment 

6.2  Support  total  ship  weight 

6.3  Minimize  total  resistance 

6.1  Enclose  personnel  and  equipment 

6.2  Support  total  ship  weight 

6.3  Minimize  total  resistance 
7.0  Maintain  Desired  Position 

7. 1  Anchor  ship  to  seafloor 

7.2  Control  Dynamic  Positioning  system 

7.3  Moor  Ship  to  Object 
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10  Components 


7.1  Anchor  ship  to  seafloor 

7.2  Control  Dynamic  Positioning  system 

7.3  Moor  Ship  to  Object 

8.0  Conduct  beach  retraction  operations 
9.0  Conduct  Firefighting  Operations 

Part  II  -  Behavior  Model 


1.0  Move  through  the  water 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
4.3.4  Safeguard  Class:  ARS  50 
Bow  Thruster 

Controllable  Reversible  Pitch  Propeller 
Diver  Support  Boat 
Fuel  system 

Oil  Transfer  Pumps  and  Floses 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Propulsion  System 
T-ARS(X) 

Specified  By  Requirements: 

Endurance 

Based  On: 

Ice  Classification 
Speed 


■ 

1.1  Produce 

1.2  Provide 

1.4  Control 

1.5  Control 

-  ;'?M 

Ref. 

propulsive  power 

porpulsive  power 

1.3  Transfer 

speed  and 

speed  and 

Ref. 

to  achieve 

at  usable  speed 

power  to  water 

direction  of 

direction  of 

sustained  speed 

(rpm) 

movement  locally 

movement  remo... 

JHE 

Figure  3  1.0  Move  through  the  water  Enhanced  FFBD 


Figure  4  1.0  Move  through  the  water  FFBD 
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10  Components 


1.1  Produce 
propulsive  power 
to  achieve 
sustained  speed 


1.2  Provide 
porpulsive  power 
at  usable  speed 
(rpm) 


1.3  Transfer 
power  to  water 


1.4  Control 
speed  and 
direction  of 
movement  locally 


1.5  Control 
speed  and 
direction  of 
movement 
remotely 


Figure  5  1.0  Move  through  the  water  N2  Diagram 
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10  Components 


Main  propulsion  engines 


Reduction  gear 


Diver  Support  Boat  Controllable  Reversible  Pitch  Profl^tehelm 

Engineering  Operating  Station  OOC2  Salvage  Assets 

Oil  Transfer  Pumps  and  Hoses  1.153  Damage  Control  Central 
1.451  Pilot  House 


Pr^am^TB^Uie 


Figure  6  1.0  Move  through  the  water  IDEFO  Diagram 
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10  Components 


1.1  Produce  propulsive  power  to  achieve  sustained  speed 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 

Controllable  Reversible  Pitch  Propeller 

Main  propulsion  engines 

OOC2  Salvage  and  Towing  Assets 

OOC2  Salvage  Assets 

T-ARS(X) 

Based  On: 

Speed 

1.2  Provide  porpulsive  power  at  usable  speed  (rpm) 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Controllable  Reversible  Pitch  Propeller 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Reduction  gear 
T-ARS(X) 

Based  On: 

Speed 

1.3  Transfer  power  to  water 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 

Controllable  Reversible  Pitch  Propeller 

Diver  Support  Boat 

OOC2  Salvage  and  Towing  Assets 

OOC2  Salvage  Assets 

T-ARS(X) 

Based  On: 

Speed 

1.4  Control  speed  and  direction  of  movement  locally 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
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10  Components 


4.3.4  Safeguard  Class:  ARS  50 
Controllable  Reversible  Pitch  Propeller 
Engineering  Operating  Station 
Oil  Transfer  Pumps  and  Hoses 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

Based  On: 

Speed 

1.5  Control  speed  and  direction  of  movement  remotely 

Allocated  To: 

1.153  Damage  Control  Central 
1.451  Pilot  House 
1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Lee  helm 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

Based  On: 

Speed 

10.0  Conduct  pollution  response 

Allocated  To: 

1.153  Damage  Control  Central 
1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Commercial  Transport  System 
Damage  control  systems  and  equipment 
Diver  Support  Boat 
Floating  Storage  Bladders 
Military  Cargo  Transport  System 
OOCl  Logistics 

OOC2  Salvage  and  Towing  Assets 
OOC25  Pollution  Logistics  Support 
OOC25  Pollution  Planning  and  Compliance 
OOC25  Pollution  Research  and  Development 
OOC25  Pollution  Response 
Open  Ocean  Skimmers 
Pollution  Containment  Booms 
SEA  OOC25  Pollution 

Ship  Service  Support  for  Host  Deployment  of  Self-contained  Oil  Spill  Suite 
Small  Skimmers 
Sorbent  Materials 
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10  Components 


T-ARS(X) 

10.1  Provides  Pollution  Logistics  support 

Allocated  To: 

Commercial  Transport  System 
Military  Cargo  Transport  System 
OOCl  Logistics 

OOC2  Salvage  and  Towing  Assets 
OOC25  Pollution  Logistics  Support 
OOC25  Pollution  Response 
SEA  OOC25  Pollution 

Ship  Service  Support  for  Host  Deployment  of  Self-contained  Oil  Spill  Suite 
T-ARS(X) 

11.0  Conduct  Pollution  Training 

Allocated  To: 

1.125  Consolidated  Divers  Unit 
1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 

OOC25  Pollution  Planning  and  Compliance 

OOC25  Pollution  Publications 

OOC25  Pollution  Research  and  Development 

OOC25  Pollution  Response 

OOC25  Pollution  Training 

SEA  OOC25  Pollution 

T-ARS(X) 

13.0  Conduct  Diving  Operations  other  than  salvage 

Allocated  To: 

1.125  Consolidated  Divers  Unit 
1.5  Afloat  Units 
4.3.4  Safeguard  Class:  ARS  50 
Communications  equipment 
Deck  Fighting 
Diver  Davits 

Diver  Deployment  Support  Stations 
Diver  Fife  Support  System  (DESS) 

Diver  Support  Boat 

OOC2  Salvage  and  Towing  Assets 

OOC2  Salvage  Assets 

Portable  Davits 

T-ARS(X) 

14.0  Conduct  Personnel  Rescue  Operations 

Allocated  To: 

1.125  Consolidated  Divers  Unit 
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10  Components 


1.451  Pilot  House 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.4  Safeguard  Class:  ARS  50 
Communieations  equipment 
CSNDL  Recompressor  Chamber 
Deck  Lighting 
Diver  Support  Boat 
Firefighting  Monitors 
Fuel  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Portable  Firefighting  Equipment 
T-ARS(X) 

15.0  Conduct  Underway  Replinishment  Operations 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Communications  equipment 
Deck  Lighting 
Fuel  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Replinishment  Stations 
T-ARS(X) 

2.0  Maintain  Desired  Course 

Allocated  To: 

1.451  Pilot  House 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Diver  Support  Boat 
Fuel  system 

Maneuvering  and  Control  System 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 


Figure  7  2.0  Maintain  Desired  Course  Enhanced  FFBD 
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10  Components 


Ref. 


Figure  8  2.0  Maintain  Desired  Course  FFBD 


2.2  Alter  existing 
course 

2.1  Determine  if 
course  is  safe 

2.3  Maneuver 
alongside  pier 

Figure  9  2.0  Maintain  Desired  Course  N2  Diagram 


no 


10  Components 


Rudder  Bow  thrusters/APU 

Bow/Stern  Roller  System 
Controllable  Reversible  Pitch  Propeller 
Diver  Support  Boat 
Fuel  system 
OOC2  Salvage  Assets 


Maneuvering  and  Coni 


Figure  10  2.0  Maintain  Desired  Course  IDEFO  Diagram 
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10  Components 


2.1  Determine  if  course  is  safe 

Allocated  To: 

1.451  Pilot  House 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Navigation  equipment 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

2.2  Alter  existing  course 

Allocated  To: 

1.451  Pilot  House 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Bow  Thruster 

OOC2  Salvage  and  Towing  Assets 

OOC2  Salvage  Assets 

Rudder 

T-ARS(X) 

2.3  Maneuver  alongside  pier 

Allocated  To: 

1.451  Pilot  House 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Bow  thrusters/APU 
Bow/Stern  Roller  System 
Controllable  Reversible  Pitch  Propeller 
Diver  Support  Boat 
Fuel  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

Based  On: 

Dynamic  Positioning 

3.0  Conduct  Salvage  Operations 

Allocated  To: 

1.125  Consolidated  Divers  Unit 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.4  Safeguard  Class:  ARS  50 
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10  Components 


9.036  Crane 

Communications  equipment 
Deck  Fastener  System 
Deck  Lighting 
Deep  Drone  7200  ROV 
Diver  Davits 

Diver  Deployment  Support  Stations 
Diver  Life  Support  System  (DLSS) 

Diver  Support  Boat 

Fabrication  Space 

Hydraulic  Power  Packs 

Ikelite  Housing  and  JVC  Camcorder 

Lateral  Control  Winch 

Main  Deck  Remote  Control  Station 

MINIROVs 

OOC2  Ocean  Search  and  Recovery  Assets 

OOC2  Salvage  and  Towing  Assets 

OOC2  Salvage  Assets 

OOC2  Search  and  Recovery  Assets 

Orion  Search  System 

Portable  Bullwarks 

Portable  Generators 

Rope  Transport  Tray 

Secondary  Crane 

Shallow  Water  Intermediate  Search  System  (SWISS) 
Shark  Jaws 

Ship  Service  Support  for  Portable  DLSS  Air  Compressor 
Ship  Service  Support  for  SAT  FADS 
Ship  Service  Support  for  SRDRS 
T-ARS(X) 

Unobstructed  Deck  Space;  Aft 
Unobstructed  Deck  Space;  Fwd 
Vacuum  Recovery  System 

Based  On: 

Dynamic  Positioning 
Primary  Crane  Lift  Capacity 
Secondary  Crane  Lift  Capacity 
Unobstructed  Deck  Space;  Aft 
Unobstructed  Deck  Space;  Fwd 


Figure  11  3.0  Conduct  Salvage  Operations  Enhanced  FFBD 
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10  Components 


■ - 

■ - 

Ref. 

3.1  Conduct 
Collision  Repair 

3.3  Retrieve 
vessel  from  beach 

3.2  Conduct 
Ocean  Search 
and  Recovery 

"I 

Figure  12  3.0  Conduct  Salvage  Operations  FFBD 


1 

3.1  Conduct 
Collision  Repair 

3.3  Retrieve 
vessel  from  beach 

3.2  Conduct 
Ocean  Search 
and  Recovery 

Figure  13  3.0  Conduct  Salvage  Operations  N2  Diagram 
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10  Components 


3.1  Conduct 
Collision  Repair 


4.3.4  Safeguard  Class 
1.5  Afloat 


OOC2  Ocean  Search  and  Refc<^A#ioAli^i5 


3.3  Retrieve 
,  vessel  from  beach 


OOC2 
1.5  Afloi] 
Safeguard  Cla:.i 
F^owhaten  Class 


Towing  Assets 
■  Orion  search  System 
MINIRO\/^ 

Deep  Drone  7200  ROV 
arch  System  (SWISS) 

-  Orion  Search  S^lsterW 
MINl|ROVte 
Maonum  ROV 


Deep  Drot 
T-/ 


I'feguara  Class: 
lifeguard  Class: 


3.2  Conduct 
Ocean  Search 
and  Recovery 


JJJJJJ 


Fabrication  Space  ^  Forward  Anchor  Capstan  IKiMfi^sfiem 

Salvage  Equipment  "  Mooring  system  Main  Deck  Remote  Control  Station 

Ship  Service  Support  for  Submariine  Salvage  SiJ^jpilisble  Bullwarks  OOC2  Salvage  Assets 

1.125  Consolidated  D1veiBodtal)le  Tow  Bow  OOC2  Search  and  Recovery  Assets 

Communications.  equiiRnser  Blocks  Secondary  Crane 

Ship  Service  Support  for  HoSb|uSer\S:$6t&iip|6ortSltiDerD^\(bseals  Search  and  Recovery 
Tow  Bows  2  1/4"  Wire 

Towing  and  Mooring  Line  Stowage  Space  9.036  Crane 
Traction  Winch 
Twin  Drum 
Aft  Capstans 
Beach  Gear 

Bow/Stern  Roller  System 


Ship  ServKVi 


Figure  14  3.0  Conduct  Salvage  Operations  IDEFO  Diagram 
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10  Components 


3.1  Conduct  Collision  Repair 

Allocated  To: 

1.125  Consolidated  Divers  Unit 
1.5  Afloat  Units 
4.3.4  Safeguard  Class:  ARS  50 
Communications  equipment 
Fabrication  Space 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Salvage  Equipment 

Ship  Service  Support  for  Submarine  Salvage  Support 
T-ARS(X) 


Figure  15  3.1  Conduct  Collision  Repair  Enhanced  FFBD 


Figure  16  3.1  Conduct  Collision  Repair  FFBD 
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10  Components 


3.1.1  Conduct 
Underwater 
Inspections 


4.3.4  Safeguard 
1.5 


3.1.2  Conduct 
Underwater 
Welding 


4.3.4  Safeguard  Cl 


4.3.4  Safeguard  Cl 
1.5  Afbi 


C2  Salvage  and  T dv\ 


AAA 

4RS5D 


Ing  /.ss 


iafvage'arTd  Tc 
n  Search  and  P 

iDCf2  Salvage  and 
et:; 

ODCf2  Salvage  and  Tb’ 


3.1  Conduct 
diving  Operations 


Boroscope  (DUCTS  CompatOfiS) Consolidated  Divers  Unit 
Deep  Sea  Power  and  Light  M6iillv0^£6c(i0panent 
Diver  Underwater  Camera  Television  System 
Ikelite  Housing  andJVC  Camcorder 
Maskerbelt  Inspection  System 


'  iV' 

m  Div 

rV  IL-olil 


Microtube  Camera 
See  Snake  Inspection  System 
MN30  Camera 


. .  '',j\  Compressed  Air  System 

.  CSNDL  Recompressor  Chamber 
Diver  Davits 

Diver  Deployment  Support  Stations 
Diver  Life  Support  System  (DLSS) 

Diver  Support  Boat 
Portable  Davits 

Ship  Service  Support  for  Portable  DLSS  Air  Compressor 
OOC2  Salvage  Assets 
Ship  Service  Support  for  SAT_FADS 
Ship  Service  Support  for  SRDRS 


Ship 


Service<5l>ppaBfTfcaiaih^ 
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10  Components 


Figure  18  3.1  Conduct  Collision  Repair  IDEFO  Diagram 

3.1  Conduct  diving  Operations 

Allocated  To: 

Compressed  Air  System 
CSNDL  Recompressor  Chamber 
Diver  Davits 

Diver  Deployment  Support  Stations 
Diver  Life  Support  System  (DLSS) 

Diver  Support  Boat 

OOC2  Ocean  Search  and  Recovery  Assets 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Portable  Davits 

Ship  Service  Support  for  Portable  DLSS  Air  Compressor 
Ship  Service  Support  for  SAT  FADS 
Ship  Service  Support  for  SRDRS 
T-ARS(X) 

Based  On: 

Dynamic  Positioning 

3.1.1  Conduct  Underwater  Inspections 

Allocated  To: 

1.125  Consolidated  Divers  Unit 
1.5  Afloat  Units 
4.3.4  Safeguard  Class:  ARS  50 
Boroscope  (DUCTS  Compatible) 

Deep  Sea  Power  and  Light  Modified  Camera 
Diver  Underwater  Camera  Television  System 
Ikelite  Flousing  and  JVC  Camcorder 
Maskerbelt  Inspection  System 
Microtube  Camera 
MN30  Camera 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
See  Snake  Inspection  System 
T-ARS(X) 

3.1.2  Conduct  Underwater  Welding 

Allocated  To: 

1.125  Consolidated  Divers  Unit 

1.5  Afloat  Units 

4.3.4  Safeguard  Class:  ARS  50 

OOC2  Salvage  and  Towing  Assets 

OOC2  Salvage  Assets 

Salvage  Equipment 

T-ARS(X) 
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3.2  Conduct  Ocean  Search  and  Recovery 

Allocated  To: 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.4  Safeguard  Class:  ARS  50 

9.036  Crane 

Curv  III  ROV 

Deep  Drone  7200  ROV 

Fuel  system 

Magnum  ROV 

Main  Deck  Remote  Control  Station 
MINIROVs 

OOC2  Ocean  Search  and  Recovery  Assets 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
OOC2  Search  and  Recovery  Assets 
Orion  Search  System 
Secondary  Crane 

Shallow  Water  Intermediate  Search  System  (SWISS) 

Ship  Service  Support  for  Deep  Ocean  Search  and  Recovery 
T-ARS(X) 

Based  On: 

Dynamic  Positioning 
Secondary  Crane  Lift  Capacity 


3.3  Retrieve 

3.2.1  Conduct 
Heavy  Lift 
Operations 

3.2.2  Conduct 

vessel  from  beach 

ROV  operations 

Figure  19  3.2  Conduct  Ocean  Search  and  Recovery  Enhanced  FFBD 


3.3  Retrieve 

3.2.1  Conduct 

3.2.2  Conduct 

vessel  from  beach 

Operations 

ROV  operations 

Figure  20  3.2  Conduct  Ocean  Search  and  Recovery  FFBD 
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3.2.1  Conduct 
Heavy  Lift 
Operations 

3.2.2  Conduct 
ROV  operations 

Figure  21  3.2  Conduct  Ocean  Search  and  Recovery  N2  Diagram 


3.2.1  Conduct 
Heavy  Lift 
Operations 


OOC2  Salvage  and  Towing 


/SS3(!t5 


4.3.4  Safeguar^^j 


las! 


Clas! 


4.3.4  Safeguard 
OOC2  Salvage  and 


Icat 


Tl-ARSI 


AFS 


liO 


lid 


3.2.2  Conduct 
ROV  operations 


'» *  b  k  4  •  • 

Deck  Fastener  System 
Deck  Lighting 

OOC2  Salvage  Assets 
Secondary  Crane 
Unobstructed  Deck  Space;  Aft 
2  1/4“  Wire 
9.036  Crane 

Unobstructed  Deck  Space;  Fwd 


Shi|SISalil6ii@ 


Figure  22  3.2  Conduct  Ocean  Search  and  Recovery  IDEFO  Diagram 
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3.2.1  Conduct  Heavy  Lift  Operations 

Allocated  To: 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.4  Safeguard  Class:  ARS  50 
9.036  Crane 
Deck  Fastener  System 
Deck  Lighting 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Secondary  Crane 
T-ARS(X) 

Unobstructed  Deck  Space;  Aft 
Unobstructed  Deck  Space;  Fwd 

Based  On: 

Dynamic  Positioning 
Primary  Crane  Lift  Capacity 
Secondary  Crane  Lift  Capacity 

3.2.2  Conduct  ROV  operations 

Based  On: 

Dynamic  Positioning 
Secondary  Crane  Lift  Capacity 

3.3  Retrieve  vessel  from  beach 

Allocated  To: 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.2  Powhaten  Class:  T-ATF  166 
4.3.4  Safeguard  Class:  ARS  50 
Aft  Capstans 
Beach  Gear 

Bow/Stern  Roller  System 
Forward  Anchor  Capstan  Windlass 
Mooring  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Portable  Bullwarks 
Portable  Tow  Bow 
Power  Blocks 

Ship  Service  Support  for  Flost  Puller  System  for  Stranded  Vessels 
T-ARS(X) 

Tow  Bows 

Towing  and  Mooring  Line  Stowage  Space 
Traction  Winch 
Twin  Drum 
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Based  On: 

Bollard  Pull 

3.3  Transport/secure  salvaged  system  or  equipment 

Allocated  To: 

Deck  Fastener  System 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

Unobstructed  Deck  Space;  Aft 
Unobstructed  Deck  Space;  Fwd 

Based  On: 

Salvage  Equipment  Stowage  Space 
Unobstructed  Deck  Space;  Aft 
Unobstructed  Deck  Space;  Fwd 

4.0  Conduct  towing  operations 

Allocated  To: 

1.451  Pilot  Flouse 
1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
Auto-tow  pins 
Bow  Thruster 

Communications  equipment 

Controllable  Reversible  Pitch  Propeller 

Deck  Lighting 

Fuel  system 

Flydraulic  Power  Packs 

OOC2  Salvage  and  Towing  Assets 

Portable  Bullwarks 

Portable  Tow  Bow 

Rope  Transport  Tray 

T-ARS(X) 

Tow  Fairleads 

Based  On: 

Bollard  Pull 


Figure  23  4.0  Conduct  towing  operations  Enhanced  FFBD 
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Figure  24  4.0  Conduct  towing  operations  FFBD 


4.1  Connect  tow 
line  to  vessel 

4.3  Tow  vessel 
through  water 

4.2  Position  ship 
for  towing 
operations 

Figure  25  4.0  Conduct  towing  operations  N2  Diagram 
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Diver  Support  Boat 


Figure  26  4.0  Conduct  towing  operations  IDEFO  Diagram 

4.1  Connect  tow  line  to  vessel 

Allocated  To: 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.2  Powhaten  Class:  T-ATF  166 

Aft  Capstans 

Bow/Stern  Roller  System 

Diver  Support  Boat 

OOC2  Salvage  and  Towing  Assets 

T-ARS(X) 
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4.2  Position  ship  for  towing  operations 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
OOC2  Salvage  and  Towing  Assets 
T-ARS(X) 

Based  On: 

Dynamic  Positioning 

4.3  Tow  vessel  through  water 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
Fuel  system 

OOC2  Salvage  and  Towing  Assets 
T-ARS(X) 

Based  On: 

Bollard  Pull 

5.0  Conduct  sustained  operations  underway 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
4.3.4  Safeguard  Class:  ARS  50 
Communications  equipment 
Controllable  Reversible  Pitch  Propeller 
Deck  Lighting 
Diver  Support  Boat 
Electrical  system 
Fuel  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Support/Auxiliary  Systems 
T-ARS(X) 


Figure  27  5.0  Conduct  sustained  operations  underway  Enhanced  FFBD 
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Figure  28  5.0  Conduct  sustained  operations  underway  FFBD 


5.1  Ensure 
habitable 
conditions 

5.2  Maintain 
equipment  in 
operating 
condition 

5.3 


Communicate 

information 


5.4  Combat 
damage 


5.5  Secure 
Condition  while 
underway 


5.6  Secure 
position  while  in 
port 


5.7  Provide 
electrical  power 


5.8  Provide  fuel 
source 


Figure  29  5.0  Conduct  sustained  operations  underway  N2  Diagram 
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10  Components 


support  /  habrtabiitly  featut^^' '  Diver  Davits  '  Communications  equipment  _i\'  Damage  control  systems  and  equipment 

Deck  Lighting  Diver  Deployment  Support  StaQotffi  Consolidated  Divers  Unill.  Fabricadon  Space 


Diver  Life  Support  System  (DLESSl  Pilot  House 
'  '  Maintenance  philosophy 
.  OOC2  ESSM 

Salvage  Equipment  Stowage  Space 


'Aft  Capstans 
Anchoring  system 
Bow/Stern  Roller  System 
'  1.4S4  Quarterdeck 

Host  SRDS  Mooring  System 
Mooring  system 


1.353  Damage  j^ntrol  Central 
OOC2  Salvage  Assets 

Fuel  system 


CantrSIlifiperflMiBtilpUiitSg 


Figure  30  5.0  Conduct  sustained  operations  underway  IDEFO  Diagram 
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5.1  Ensure  habitable  conditions 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Crew  support  /  habitablitiy  features 
Deck  Lighting 
Electrical  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

Based  On: 

Civilian  Crew 

Navy  Personnel  Accomodation 

5.2  Maintain  equipment  in  operating  condition 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powbaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Damage  control  systems  and  equipment 
Diver  Davits 

Diver  Deployment  Support  Stations 
Diver  Life  Support  System  (DESS) 

Electrical  system 
Maintenance  philosophy 
OOC2  ESSM 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Salvage  Equipment  Stowage  Space 
T-ARS(X) 

5.3  Communicate  information 

Allocated  To: 

1.125  Consolidated  Divers  Unit 
1.451  Pilot  Flouse 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Communications  equipment 
Electrical  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 


128 


10  Components 


5.4  Combat  damage 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Damage  control  systems  and  equipment 
Fabrication  Space 
Firefighting  Monitors 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

5.5  Secure  Condition  while  underway 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

5.6  Secure  position  while  in  port 

Allocated  To: 

1.454  Quarterdeck 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Aft  Capstans 
Anchoring  system 
Bow/Stern  Roller  System 
Flost  SRDS  Mooring  System 
Mooring  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

5.7  Provide  electrical  power 

Allocated  To: 

1.153  Damage  Control  Central 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Electrical  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Portable  Generators 
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T-ARS(X) 

5.8  Provide  fuel  source 

Allocated  To: 

1.153  Damage  Control  Central 
1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
4.3.4  Safeguard  Class:  ARS  50 
Fuel  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

6.0  Operate  on  surface  of  water 

Allocated  To: 

1.451  Pilot  Flouse 
1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
4.3.4  Safeguard  Class:  ARS  50 
9.036  Crane 
Aft  Capstans 
Bow  Thruster 

Communications  equipment 
Diver  Support  Boat 
FIull  Form 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 


Ref. 


6.1  Enclose 
personnel  and 
equipment 


6.2  Support  total 
ship  weight 


6.3  Minimize  total 
resistance 


Figure  31  6.0  Operate  on  surface  of  water  Enhanced  FFBD 


Ref. 


6.1  Enclose 
personnel  and 
equipment 


6.2  Support  total 
ship  weight 


6.3  Minimize  total 
resistance 


Figure  32  6.0  Operate  on  surface  of  water  FFBD 
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6.1  Enclose 
personnel  and 
equipment 

6.2  Support  total 
ship  weight 

6.3  Minimize  total 
resistance 

Figure  33  6.0  Operate  on  surface  of  water  N2  Diagram 
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ComitiiHnSSIHMq 

Figure  34  6.0  Operate  on  surface  of  water  IDEFO  Diagram 

6.1  Enclose  personnel  and  equipment 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
4.3.4  Safeguard  Class:  ARS  50 
Hull 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
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T-ARS(X) 

Based  On: 

Salvage  Equipment  Stowage  Space 

6.2  Support  total  ship  weight 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Displaced  hull  form  volume 
Diver  Support  Boat 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

6.3  Minimize  total  resistance 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Diver  Support  Boat 
Hull  form  characteristics 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

7.0  Maintain  Desired  Position 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Aft  Capstans 
Anchoring  system 
Bow  Thruster 

Controllable  Reversible  Pitch  Propeller 
Dynamic  Positioning 
Forward  Anchor  Capstan  Windlass 
Fuel  system 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 
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Ref. 

Vi 


Figure  35  7.0  Maintain  Desired  Position  Enhanced  FFBD 


Ref. 

7.1  Anchor  ship 
to  seafloor 

7.2  Control 
Dynamic 

Positioning  system 

7.3  Moor  Ship  to 
Object 

Figure  36  7.0  Maintain  Desired  Position  FFBD 


7.1  Anchor  ship 
to  seafloor 

7.2  Control 
Dynamic 

Positioning  system 

7.3  Moor  Ship  to 
Object 

Figure  37  7.0  Maintain  Desired  Position  N2  Diagram 
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Anchoring  system  1.153  Damage  Control  Central  1.451  Pilot  House 

Bow/Stern  Roller  System  Bow  Thruster  2  1/4“  Wire 


Aft  Capstans 

Forward  Anchor  Capstan  Windlass 
Host  SRDS  Mooring  System 
OOC2  Salvage  Assets 
Portable  Bullwarks 


Co  nt  ro  1 1  a  i1 


Figure  38  7.0  Maintain  Desired  Position  IDEFO  Diagram 
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7.1  Anchor  ship  to  seafloor 

Allocated  To: 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Anchoring  system 
Bow/Stern  Roller  System 
Forward  Anchor  Capstan  Windlass 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

7.2  Control  Dynamic  Positioning  system 

Allocated  To: 

1.153  Damage  Control  Central 
1.451  Pilot  Flouse 

1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Bow  Thruster 

OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
T-ARS(X) 

7.3  Moor  Ship  to  Object 

Allocated  To: 

1.451  Pilot  Flouse 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Aft  Capstans 

Forward  Anchor  Capstan  Windlass 
Flost  SRDS  Mooring  System 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Portable  Bullwarks 
T-ARS(X) 

8.0  Conduct  beach  retraction  operations 

Allocated  To: 

1.125  Consolidated  Divers  Unit 

1.5  Afloat  Units 
2  1/4"  Wire 

4.3.2  Powhaten  Class:  T-ATF  166 

4.3.4  Safeguard  Class:  ARS  50 
Aft  Capstans 
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Beach  Gear 

Bow/Stern  Roller  System 

Controllable  Reversible  Pitch  Propeller 

Forward  Anchor  Capstan  Windlass 

Flydraulic  Power  Packs 

Lateral  Control  Winch 

OOC2  Salvage  and  Towing  Assets 

OOC2  Salvage  Assets 

Portable  Bullwarks 

T-ARS(X) 

9.0  Conduct  Firefighting  Operations 

Allocated  To: 

1.153  Damage  Control  Central 
1.5  Afloat  Units 

4.3.2  Powhaten  Class:  T-ATF  166 
4.3.4  Safeguard  Class:  ARS  50 
Damage  control  systems  and  equipment 
Firefighting  Monitors 
OOC2  Salvage  and  Towing  Assets 
OOC2  Salvage  Assets 
Portable  Firefighting  Equipment 
T-ARS(X) 

Based  On: 

Firefighting  Flow  Rate 


Part  I  -  Hierarchical  Component  List 
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T-ARS(X) 

1 00  Hull  structure 

Hull 

Hull  Form 

Hull  form  characteristics 
200  Propulsion  plant 
300  Electric  plant 
400  Command  and  surveillance 
500  Auviliary  system 
600  Outfit  and  furnishings 
700  Armament 
800  Integration/Engineering 
900  Ship  assembly  and  support  systems 

Part  II  -  Component  Definitions 
T-ARS(X) 

Built  In  Higher-Eevel  Component(s): 

1.5  Afloat  Units 

Built  From  Eower-Eevel  Component(s): 

100  Hull  structure 

200  Propulsion  plant 

300  Electric  plant 

400  Command  and  surveillance 

500  Auviliary  system 

600  Outfit  and  furnishings 

700  Armament 

800  Integration/Engineering 

900  Ship  assembly  and  support  systems 
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100  Hull  structure 


nil 


200  Propulsion  plant 


nil 


300  Electric  plant 


nil 


400  Command  and 
surveillance 


nil 


500  Auvillary  system 


nil 


600  Outfit  and 
furnishings 


nil 


700  Armament 


nil 


800 

Integration/ 

Engineering 

nil 


900  Ship  assembly 
and  support  systems 


nil 


Figure  39  T-ARS(X)  Subcomponent  Connectivity 


Performs  Function(s): 

1.0  Move  through  the  water 

1 . 1  Produce  propulsive  power  to  achieve  sustained  speed 

1.2  Provide  porpulsive  power  at  usable  speed  (rpm) 

1.3  Transfer  power  to  water 

1.4  Control  speed  and  direction  of  movement  locally 

1.5  Control  speed  and  direction  of  movement  remotely 
10.0  Conduct  pollution  response 

10.1  Provides  Pollution  Logistics  support 
1 1.0  Conduct  Pollution  Training 

13.0  Conduct  Diving  Operations  other  than  salvage 
14.0  Conduct  Personnel  Rescue  Operations 
15.0  Conduct  Underway  Replinishment  Operations 
2.0  Maintain  Desired  Course 

2. 1  Determine  if  course  is  safe 

2.2  Alter  existing  course 

2.3  Maneuver  alongside  pier 
3.0  Conduct  Salvage  Operations 
3.1  Conduct  Collision  Repair 
3.1  Conduct  diving  Operations 
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3.1.1  Conduct  Underwater  Inspections 

3.1.2  Conduct  Underwater  Welding 

3.2  Conduct  Ocean  Search  and  Recovery 

3.2.1  Conduct  Heavy  Lift  Operations 

3.3  Retrieve  vessel  from  beach 

3.3  Transport/secure  salvaged  system  or  equipment 
4.0  Conduct  towing  operations 

4. 1  Connect  tow  line  to  vessel 

4.2  Position  ship  for  towing  operations 

4.3  Tow  vessel  through  water 

5.0  Conduct  sustained  operations  underway 

5. 1  Ensure  habitable  conditions 

5.2  Maintain  equipment  in  operating  condition 

5.3  Communicate  information 

5.4  Combat  damage 

5.5  Secure  Condition  while  underway 

5.6  Secure  position  while  in  port 

5.7  Provide  electrical  power 

5.8  Provide  fuel  source 

6.0  Operate  on  surface  of  water 

6. 1  Enclose  personnel  and  equipment 

6.2  Support  total  ship  weight 

6.3  Minimize  total  resistance 
7.0  Maintain  Desired  Position 

7. 1  Anchor  ship  to  seafloor 

7.2  Control  Dynamic  Positioning  system 

7.3  Moor  Ship  to  Object 

8.0  Conduct  beach  retraction  operations 
9.0  Conduct  Firefighting  Operations 

Specified  By: 

Bollard  Pull 
Civilian  Crew 
Dynamic  Positioning 
Endurance 

Firefighting  Flow  Rate 

Ice  Classification 

Navy  Personnel  Accomodation 

Primary  Crane  Eift  Capacity 

Salvage  Equipment  Stowage  Space 

Secondary  Crane  Eift  Capacity 

Speed 

Unobstructed  Deck  Space;  Aft 
Unobstructed  Deck  Space;  Fwd 

100  Hull  structure 

Built  In  Higher-Eevel  Component(s): 

T-ARS(X) 

Built  From  Eower-Eevel  Component(s): 
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10  Components 


Hull 

Hull  Form 

Hull  form  characteristics 


Hull 


nil 


Hull  Form 


nil 


Hull  form 
characteristics 


nil 


Figure  40  100  Hull  structure  Subcomponent  Connectivity 


Hull 

Built  In  Higher-Level  Component(s): 

100  Hull  structure 

Performs  Function(s): 

6. 1  Enclose  personnel  and  equipment 

Hull  Form 

Built  In  Higher-Level  Component(s): 

100  Hull  structure 

Performs  Function(s): 

6.0  Operate  on  surface  of  water 

Hull  form  characteristics 

Built  In  Higher-Level  Component(s): 

100  Hull  structure 

Performs  Function(s): 

6.3  Minimize  total  resistance 

200  Propulsion  plant 

Built  In  Higher-Level  Component(s): 
T-ARS(X) 

300  Electric  plant 

Built  In  Higher-Level  Component(s): 
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10  Components 


T-ARS(X) 

400  Command  and  surveillance 

Built  In  Higher-Level  Component(s): 
T-ARS(X) 

500  Auviliary  system 

Built  In  Higher-Level  Component(s): 
T-ARS(X) 

600  Outfit  and  furnishings 

Built  In  Higher-Level  Component(s): 
T-ARS(X) 

700  Armament 

Built  In  Higher-Level  Component(s): 
T-ARS(X) 

800  Integration/Engineering 

Built  In  Higher-Level  Component(s): 
T-ARS(X) 

900  Ship  assembly  and  support  systems 

Built  In  Higher-Level  Component(s): 
T-ARS(X) 
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Part  I  -  Derived  Functional  Interfaces 


Part  II  -  Logical  Interfaces 


Part  III  -  Physical  Interfaces 
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Allocated  Capabilities/Requirements 


Traced  From  Higher-Level  Elements 


T-ARS(X)  (Component) 


1.0  Move  through  the  water  (Funetion) 


Enduranee  (Requirement) 


1.1  Produee  propulsive  power  to  aehieve  sustained 
speed  (Funetion) 


1.2  Provide  porpulsive  power  at  usable  speed  (rpm) 
(Funetion) 


1.3  Transfer  power  to  water  (Funetion) 


1.4  Control  speed  and  direetion  of  movement  loeally 
(Funetion) 


1.5  Control  speed  and  direetion  of  movement  remotely 
(Funetion) 


10.0  Conduet  pollution  response  (Funetion) 


10.1  Provides  Pollution  Logisties  support  (Funetion) 


1 1 .0  Conduet  Pollution  Training  (Funetion) 


13.0  Conduet  Diving  Operations  other  than  salvage 
(Funetion) 


14.0  Conduet  Personnel  Reseue  Operations  (Funetion) 


15.0  Conduet  Underway  Replinishment  Operations 


Speed  (Requirement) 

lee  Classifieation  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 
1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


Speed  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 
1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


Speed  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 
1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


Speed  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 
1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


Speed  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 
1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


Speed  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 
1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 


OOC2  Salvage  and  Towing  Assets  (Component) 


1.5  Afloat  Units  (Component) 


OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 


OOC2  Salvage  and  Towing  Assets  (Component) 
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Allocated  Capabilities/Requirements 

Traced  From  Higher-Level  Elements 

(Function) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

2.0  Maintain  Desired  Course  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

2. 1  Determine  if  course  is  safe  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

2.2  Alter  existing  course  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

2.3  Maneuver  alongside  pier  (Function) 

Dynamic  Positioning  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

3.0  Conduct  Salvage  Operations  (Function) 

Unobstructed  Deck  Space;  Fwd  (Requirement) 

Primary  Crane  Lift  Capacity  (Requirement) 

Secondary  Crane  Lift  Capacity  (Requirement) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  and  Towing  Assets  (Component) 
Unobstructed  Deck  Space;  Aft  (Requirement) 

Dynamic  Positioning  (Requirement) 

OOC2  Salvage  Assets  (Component) 

3.1  Conduct  Collision  Repair  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

3.1  Conduct  diving  Operations  (Function) 

Dynamic  Positioning  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

OOC2  Salvage  Assets  (Component) 

3.1.1  Conduct  Underwater  Inspections  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

3.1.2  Conduct  Underwater  Welding  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

3.2  Conduct  Ocean  Search  and  Recovery  (Function) 

Dynamic  Positioning  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

Secondary  Crane  Lift  Capacity  (Requirement) 

OOC2  Salvage  Assets  (Component) 
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Allocated  Capabilities/Requirements 

Traced  From  Higher-Level  Elements 

3.2.1  Conduct  Heavy  Lift  Operations  (Function) 

Primary  Crane  Lift  Capacity  (Requirement) 

Secondary  Crane  Lift  Capacity  (Requirement) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  and  Towing  Assets  (Component) 

Dynamic  Positioning  (Requirement) 

OOC2  Salvage  Assets  (Component) 

3.3  Retrieve  vessel  from  beach  (Function) 

Bollard  Pull  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

3.3  Transport/secure  salvaged  system  or  equipment 
(Function) 

Salvage  Equipment  Stowage  Space  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 
Unobstructed  Deck  Space;  Aft  (Requirement) 
Unobstructed  Deck  Space;  Fwd  (Requirement) 

OOC2  Salvage  Assets  (Component) 

4.0  Conduct  towing  operations  (Function) 

Bollard  Pull  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

4. 1  Connect  tow  line  to  vessel  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

4.2  Position  ship  for  towing  operations  (Function) 

Dynamic  Positioning  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

4.3  Tow  vessel  through  water  (Function) 

Bollard  Pull  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

5.0  Conduct  sustained  operations  underway  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

5.1  Ensure  habitable  conditions  (Function) 

Navy  Personnel  Accomodation  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

Civilian  Crew  (Requirement) 

OOC2  Salvage  Assets  (Component) 

5.2  Maintain  equipment  in  operating  condition 
(Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

5.3  Communicate  information  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 
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Allocated  Capabilities/Requirements 

Traced  From  Higher-Level  Elements 

5.4  Combat  damage  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

5.5  Secure  Condition  while  underway  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

5.6  Secure  position  while  in  port  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

5.7  Provide  electrical  power  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

5.8  Provide  fuel  source  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

6.0  Operate  on  surface  of  water  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

6. 1  Enclose  personnel  and  equipment  (Function) 

Salvage  Equipment  Stowage  Space  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

6.2  Support  total  ship  weight  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

6.3  Minimize  total  resistance  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

7.0  Maintain  Desired  Position  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

7. 1  Anchor  ship  to  seafloor  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

7.2  Control  Dynamic  Positioning  system  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

7.3  Moor  Ship  to  Object  (Function) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 
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Allocated  Capabilities/Requirements  Traced  From  Higher-Level  Elements 

8.0  Conduct  beach  retraction  operations  (Function)  OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

9.0  Conduct  Firefighting  Operations  (Function)  Firefighting  Flow  Rate  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

Bollard  Pull  (Requirement) 

Civilian  Crew  (Requirement) 

Dynamic  Positioning  (Requirement) 

Endurance  (Requirement) 

Firefighting  Flow  Rate  (Requirement) 

Ice  Classification  (Requirement) 

Navy  Personnel  Accomodation  (Requirement) 

Primary  Crane  Lift  Capacity  (Requirement) 

Salvage  Equipment  Stowage  Space  (Requirement) 

Secondary  Crane  Lift  Capacity  (Requirement) 

Speed  (Requirement) 

Unobstructed  Deck  Space;  Aft  (Requirement) 

Unobstructed  Deck  Space;  Fwd  (Requirement) 

100  Hull  structure  (Compoueut) 

Hull  (Compoueut) 

6. 1  Enclose  personnel  and  equipment  (Function)  Salvage  Equipment  Stowage  Space  (Requirement) 

OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

Hull  Form  (Compoueut) 

6.0  Operate  on  surface  of  water  (Function)  OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

Hull  form  characteristics  (Compoueut) 

6.3  Minimize  total  resistance  (Function)  OOC2  Salvage  and  Towing  Assets  (Component) 

1.5  Afloat  Units  (Component) 

OOC2  Salvage  Assets  (Component) 

200  Propulsion  plant  (Component) 

300  Electric  plant  (Component) 

400  Command  and  surveillance  (Component) 
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Allocated  Capabilities/Requirements 

Traced  From  Higher-Level  Elements 

500  Auviliary  system  (Component) 

600  Ontfit  and  fnrnishings  (Component) 

700  Armament  (Component) 

800  Integration/Engineering  (Component) 

900  Ship  assembly  and  snpport  systems 
(Component) 
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